prolic on v1.10.3
prolic on master
update changelog (compare)
prolic on master
fix restarting projection durin… respect lock in memory resetting projection and 12 more (compare)
I'm suggesting to inject your
Prooph\EventStore\EventStore service into your finder and use
EventStore::load directly (check the link I shared for an example), instead of using the projection manager that is aimed to track the status of your projectors.
The reason being that your projector does not need to be tracked, because it reads all the relevant events from the start, every time.
That being said, what you did is probably working fine (however you're adding an unecessary overhead by querying the "projections" table, aren't you?).
🎉 The new #proophboard wiki is online 🎉
💄New layout supporting light and dark mode as well as different font sizes
🧭️ New sidebar with better structure and much easier navigation
💡More content incl. #eventstorming basics + guideline
🙏 Please have a look and tell me what you think. Feedback is very much appreciated.
Good afternoon, our application is currently implemented using the
So far we have around 15k players and in the
Player stream we have around 8 million events (related to the 15k players)
When we have a huge amount of events at the same time (sometimes because of huge backlog), we find that the query that loads the actual player aggregate is taking much more time (around 1/2 second) that in normal scenarios.
SELECT * FROM "_889c6853a117aca83ef9d6523335dc065213ae86" WHERE metadata->>? = $1 AND metadata->>? = $2 AND CAST(metadata->>? AS INT) > $3 AND no >= $4 ORDER BY no ASC LIMIT $5
Technically its not an issue per-se for our product as its still fast, but we were wondering if moving to a different strategy might actually solve it and make it more future proof
So we opted to see how it would behave by moving to
AggregateStreamStrategy by changing the
true in the player
AggregateRepository. We also did a projection to migrate the events on the into the different streams (tables) therefore ended up with 15k tables and in itself it helps now with querying the aggregate repository because each stream is much smaller since its per player
Having said that projections deteriorate drastically since they have to consume over 15k tables to be updated. We know that this could be possible as it is stated in the documentation of the AggregateStreamStrategy (http://docs.getprooph.org/event-store/implementations/pdo_event_store/variants.html#3-2-1-2-5-1)
PS we did update the projections to use
fromCategory instead of
anyone has managed to overcome such scenario
@andrew.magri_gitlab Did you consider using snapshots to speed up aggregate loading?
8 million events in a single stream shouldn't be a problem.
The idea would be to write an event store plugin that hooks into the transaction to write events (or references) also into a category stream and let projections only subscribe to the category and not the aggregate streams.
Another option is to switch to prooph/event-store v8 and use EventStoreDB ;) That would be the safest path for the future even with a lot more players and events in the system.
yes we are using snapshots. I guess on a daily basis its around 50ms to load but when we have this issue that the source is halted and we get huge batches of data it struggles a bit. kind off we find that sometimes takes half a seconds... with data of around 1 week sent together
so its reasonable but still
Another option is to switch to prooph/event-store v8 and use EventStoreDB ;) That would be the safest path for the future even with a lot more players and events in the system
so with EventStoreDB I would have better performance for
we are currently using
Hey, I'm thinking about a revival of prooph/event-sourcing but in a totally new way and it would be nice to get some feedback regarding the idea:
@sandrokeil had the idea to create a plugin for Cody (https://youtu.be/0FAgsPNqUV4) that generates framework agnostic domain model code: aggregates, value objects, messages, handlers, ... from a prooph board event map.
One reason to abandon prooph/event-sourcing was that it creates a framework dependency in your business logic. Something you don't really want. So instead you should use the package as inspiration only. But what if you could have a code generator, that generates all the glue code for you in the namespace of your choice?
One can then connect the result with the framework of their choice. We think about prooph/event-store and Ecotone packages that can be used in combination to also generate framework related glue code (e.g. repository implementation, PHP8 attributes for Ecotone, ...)
Would you be interested in such a package?