search

ananthakumaran / fdb

FoundationDB client for Elixir
MIT License
51 stars 5 forks source link

Is there any significative difference between the new non-released Future api and the old approach? #10

Closed WolfDan closed 2 years ago

WolfDan commented 5 years ago

Hey,

as the title said I'm curious if there's any significant use for the new api on the master branch. From my understanding the futures on fdb are objects that represent a value that will be return a value when if need on block operations, but from my perspective the actual api looks like already does that, doesn't it? If so why the new Future api?

Thank you

ananthakumaran commented 5 years ago

API wise, there shouldn't be any breaking changes. The changes are mostly extra additions that might be useful in certain cases. I think the parallel to Future might be javascript promises, the last released version had map. Master now contains extra functions like then and all. I am still figuring out some of the implementation details. But this would be essential if one wants to do everything asynchronously. A sample usage can be found here https://github.com/ananthakumaran/fdb_layer/commit/67db14d334f753d306a4b9c2a7dfc0abe6faab42

PS: btw don't depend on the API on the master. At least wait for a release because I am still trying to understand if it's the correct direction

WolfDan commented 5 years ago

But this would be essential if one wants to do everything asynchronously.

I think this is out of topic, maybe I'm wrong but that could make the system run out resources if there's too many concurrent transactions, no?

PS: btw don't depend on the API on the master. At least wait for a release because I am still trying to understand if it's the correct direction

Oh all right, I was curious about it since I saw your fdb layer ^^

ananthakumaran commented 5 years ago

But this would be essential if one wants to do everything asynchronously.

I think this is out of topic, maybe I'm wrong but that could make the system run out resources if there's too many concurrent transactions, no?

We have to define how many is too many. My current use case is about making multiple independent read/write on a single transaction.

1) read primary key and update value 2) read secondary key and update value ...

All these operations are not dependent on each other. We could either spin up a new process for each operation like Task.async and then use the Task module for coordination. We may be spining too many new processes with this approach. With async api, one could use Future.all([a, b, c]) to wait for all the operations to finish.

WolfDan commented 5 years ago

My current use case is about making multiple independent read/write on a single transaction.

But the actual api already does that, no? Just sending the current created transaction