StoredEvent UUID Support - Drop requirement for int Id?

[Shkeats]

I've been looking into making an open source DynamoDB driver package for laravel-event-sourcing.

The way the package currently abstracts the Eloquent layer behind interfaces and does not require use of the Eloquent model for StoredEvent is great and makes this much easier, however one clear blocker to me is the int typing around the $id attribute on StoredEvent. DynamoDB doesn't natively support an incrementing id and I suspect this problem would apply to most distributed data stores.

It seems the int id plays double duty as a unique id and also sort key to preserve order within the Eloquent implementations of StoredEvents, however it looks to me its 'integerness' is not depended on elsewhere in the package beyond this.

TLDR: Would you be open to a PR relaxing the typing on the id property of StoredEvent, and the related find() method on StoredEventRepository and ShouldBeStored's storedEventId metadata get/set methods in a future version to allow for string ids for those implementing their own event stores? It's a breaking change of course so major version worthy, but I can't forsee it being a big upgrade burden on any end users and it would make the package more extensible.

If it's a no, I totally understand, it would just be good to know as I would instead need to build as a fork or a new project inspired by this one rather than a driver for your package that provides implementations for SnapshotRepository and StoredEventRepository.

Thanks in advance for your consideration.

Shaun

[Shkeats]

I've engineered around this for now by generating incrementing 64bit ids using the microsecond timestamp and a sprinkle of random digits on the end to increase collision resisitance. https://github.com/blackfrog-co/laravel-event-sourcing-dynamodb/blob/main/src/IdGeneration/TimeStampIdGenerator.php