Closed rbino closed 1 year ago
~~Another reason why this probably makes sense: the current API is designed in a way that makes the user think an AccountBatch can be shared across processes (since it's internally protected with a Mutex etc), but it's actually prone to race conditions in the current state, since add_{account,transfer}
bumps the batch length and then sets the fields of the last entry one by one, and if two different processes do this operation simultaneously all hell could break lose.
So in reality we probably want an atomic bump length + append binary, and possibly some setters.~~
Edit: this was actually fixed in https://github.com/rbino/tigerbeetlex/commit/66e0bdf23a6ffbe0c1f253690186e42769085a61. Keeping the issue open to keep evaluating single shot binary set vs many setters with the tradeoffs discussed above.
Note that to be quite honest we already "hardcode" the structure of Account
and Transfer
to decode them using binary pattern matching, so adding the same in reverse would probably not worsen the situation
Right now we add a spot and then set all the single fields, but the high level API already accepts a full account/transfer so we might as well serialize it to binary on the Elixir side and just send the whole binary so we can add an account/transfer to the batch and just copy the binary over. The disadvantage of this approach is that the code that serializes the Account/Transfer could go out of sync with the actual Tigerbeetle struct.