-
Notifications
You must be signed in to change notification settings - Fork 22
Support time-based event store queries #23
Comments
Indeed, time travel is important, but that is done by traversing a stream of ordered events, not necessarily by using timestamps. In You are free to add your own timestamps to an event store! In particular, this is really easy with the SQL event stores: just add a You could also add timestamps to events explicitly and deal with generating them yourself. Just wrap your event type in a data type with |
Fair point, I just prefer to refer to time explicitly when doing so. :)
Right, but the thing is that I want
Problem with that is that filtering would then have to be implemented in the application rather than the database query, and will get quite heavy with a long event stream. |
My point is you don't need You can think of
That's not true. You can still use the database like you normally would.
There are more practical issues with timestamps to consider as well:
Certainly timestamps on every event are useful as metadata. However, if you need timestamps as part of your business logic, they really should be included in the actual events. Then, if you want to do arbitrary time-based queries, you should have a read model that listens to all events from the main event store, and then projects them in such a way that time-based querying is easy and quick. |
There's currently no way to do time-based queries on the event store since timestamps aren't recorded unless you add them to your event types explicitly. They should be added to the
StoredEvent
type, or a new type along with a newEventStore
should be created.One of the most important use cases for event sourcing is to support time travel, and if the event store doesn't have any notion of time, this is impossible. I'm interested in hearing the reasons for not including it, but given the goals of event sourcing, it seems too important to exclude.
The text was updated successfully, but these errors were encountered: