The new 620 API adds fdb_transaction_get_approximate_size which returns a future:
// This function intentionally returns an FDBFuture instead of an integer directly,
// so that calling this API can see the effect of previous mutations on the transaction.
// Specifically, mutations are applied asynchronously by the main thread. In order to
// see them, this call has to be serviced by the main thread too.
DLLEXPORT WARN_UNUSED_RESULT FDBFuture*
fdb_transaction_get_approximate_size(FDBTransaction* tr);
I already had something similar to option 1, a property on transaction objects that tried to keep a count of the mutation size done so far. This property is being used in a lot of while(…) loops that try to fill up transactions up to some threshold before committing and starting a new one (for bulk inserts, things like that).
The new method is async, which makes it a bit awkward to drop into older code that was using a property before, but the comments seems to indicate that the future will only touch the client’s thread, and not the network, so the latency may be small enough to ignore…?
Will the future always complete immediately - like some already existing futures such as fdb_database_create_transaction - or is it possible to have a significant latency to obtain the value? Does this depends if there are concurrent writes on the same transaction handle or not?
I was maybe wondering exposing the result as a ValueTask<long> in .NET, which is a task-like object optimized for futures that are almost always already completed (like cached values or when reading paged resultsets from the network), but if the value is not immediately available, it would be better to expose as a Task<long> (optimized for results that are not yet available)… though it comes with a significant memory and CPU overhead…
Should I may keep an even more approximate property that is not async (for algorithm that want to fill up a transaction) and only use fdb_transaction_get_approximate_size when I want a more precise value?