Events commit position diffs when appended compare to read

[hallgren]

The WriteResult response from an append to a stream include the CommitPosition. Ex: 43033 When I later reads one event that was appended with the CommitPosition 43033. The event Position/Commit is 18446744073709551615

[YoEight]

Unless you read that event when using the ReadAll function, you won't have the real commit position of that event. You'll have the max int value instead.

[hallgren]

Is that by design?

That means when events are appended they have the commit position but when they are read from there original stream that value is missing as its only accessible from the $all stream?

Another question: When appending more than one event the WriteResult holds one commit position. Is it possible to calculate each events position from the returned commit position? To be able to know each appended events global position?

[YoEight]

Is that by design?

Yes. When reading with ReadStream, the database reads from the index which doesn't have that information. ReadAll read the transaction log directly hence why it's available. That might be resolved in future database releases. I don't have ETA though.

Another question: When appending more than one event the WriteResult holds one commit position. Is it possible to calculate each events position from the returned commit position? To be able to know each appended events global position?

Technically, 90% of the time, yes. AppendToStream returns the last event's commit position. So if you know how the data is laid out on the transaction log, it's doable. Don't expect any help from the client though.

Question is, why would you need that information for each event of the batch?

[hallgren]

I have written a event sourcing pkg where the events include the global version. With sql, the event store uses the auto incremented index to represent the global version.

With the esdb events store I try to fit into some common ground from the overlaying event structure.

[YoEight]

It's possible to hack something similar here but it will require some actions on your side. You could use a user-defined projection set in the database that will link all user events to a specific stream: let's call it all_events. All you would have to do is use the all_events event numbers as global position.

[hallgren]

Great, I try that. Thanks for your time.

[YoEight]

Note that soon, we will have something built-in for this kind of indexing need that will not involve you doing that type of work. Stay tuned!

[hallgren]

That sound great. Currently I will not populate the GlobalVersion property when reading events from an entity stream. If the commit position is available on each event in any stream that would help.