Releases: tomasaschan/RdbmsEventStore
.NET 4.6.1 support for EF Core bindings
This release brings no code changes - it just adds .NET 4.6.1 as a build target for the new EF Core bindings.
Package metadata for RdbmsEventStore.EFCore
This is just a patch release to get correct package metadata on the EF Core bindings NuGet package.
If you want to make pancakes...
This release has two sets of breaking changes:
- A couple of classes in the Entity Framework 6 provider were renamed (#45)
- We no longer expose the version number in the event store. Instead, the timestamp is used for concurrency checks (#47, #48)
The sample applications have been updated to a beta build which is built from the same commit as in this release, but from before the release was published to NuGet.
EF Core support!
Timestamp ordering and various simplifications
Improvements in this release:
- #35 Order events by timestamp (fixes #34)
- #36 Simplify event stream
- #37 Extract QueryableExtensions into its own NuGet package
The major breakage from this release is that I've renamed IEventStream
back to IEventStore
. The reasoning behind this decision is outlined in #36, but it should remain stable from here on.
Extend querying capabilities
Improvements in this release:
- #33 Query all events
Update dependencies
Notable changes:
- #30 Removes dependency on System.ValueTuple.
Re-vamp storage
Major changes:
- #26 Separates storage type from event metadata container
- #29 Lock event store per stream, to enable better concurrency (fixes #25)
Improvements and fixes:
Summary:
Before, it was pretty awkward to get a hold of both the metadata of an event (timestamp, version etc) and the actual payload, because the payload was stored in serialized form on the metadata wrapper.
In this release, the storage type of the event is separated from the metadata container, making it easier to create state projections that use the metadata as well as the payload.
Improved extensibility
Improvements:
Summary:
This library was designed to not force anything upon you, but apparently some of the generic constraints where a little, well, constraining. Now, you're free to use whatever classes you want for the event storage type and the db context, as long as they implement the required interfaces.
Decoupled ID types
Enhancements:
It is now possible to use different types for the event id, and the stream ids.
Usually, you'll want something like long
or Guid
for your event ids, but the stream id is not so rigid - it might make sense to use a string
built from the aggregate type and id, for example. But since string
is probably not a good choice of PK for the event table, they are now completely decoupled.