Hi Kuba, great presentation - thanks for sharing! I could be wrong but if we are getting changes from user as the immutable copy of the current state, shouldn't we flush with changes.removeAll(currentChanges) and not changes.clear()? Isn't there any possibility that we've received some new events in the meantime of executing our persistence methods and we would lose them by just clearing the hash map?
Thanks for the video! This technique is pretty commonly used in event driven simulations. But I think it has few drawbacks when used in enterprise solutions - please correct me if I'm wrong: - It looks nice for simple entity, but how this would scale with even-not-so-complex object graph? - Secondly, what about displaying a list of eg. 100 objects in current (newest) state, when each one has to be recreated from many events? Recreating this from events may be super slow there... Should we introduce "standard" repository and store both events and current object in persistence? If so, how this differs from out of the box solutions like Envers? - EventSourcedUserRepository looks like extreme thread-unsafe code... For example, what if new events were collected between user.getChanges() and user.flushChanges()? You may say that user shouldn't be used in multithreaded environment and new instance should be used instead. But even then, how would you achieve events order in your repository when there are multiple writers? Yes, you may say that this would require some conceptual rewriting which isn't covered in this presentation, but isn't it about? Anyway idea sounds really interesting and I'd love to see it in real app.
Hi, Thanks for your comments 1) I don't understand the " out the graph " part of the comment - normally you have a one root object which manages the lifecycle of the whole graph. If does not matter if that's a custom entity or Integer :) 2) You are thinking about projections here and you are right. With events it would be slow. That is why in the second part of the talk I am talking about read models and CQRS for querying 100 objects in a specific state. Envers is all about state (so it forgets the reasons between state changes), whereas event sourcing is all about why we change from state A to B. 3) You are right! This is a demo, not production ready in memory hashmap which is not thread-safe :) You might want to implement optimistic locking. Then you are sure that events are in the correct order.
I like how he goes straight to TDD even for a demo
Great Demonstration. Guy is really skilled & was well prepared. Thank you Jakub & SpringDeveloper for this.
Audio quality is a bit disappointing. But other than that a great talk
Isn't t better to have activate/deactivate methods idempotent instead of throwing Exceptions?
Hi Kuba, great presentation - thanks for sharing!
I could be wrong but if we are getting changes from user as the immutable copy of the current state, shouldn't we flush with changes.removeAll(currentChanges) and not changes.clear()?
Isn't there any possibility that we've received some new events in the meantime of executing our persistence methods and we would lose them by just clearing the hash map?
True you must remove all included in the local copy else you will lose new received events.
Thanks for the video! This technique is pretty commonly used in event driven simulations. But I think it has few drawbacks when used in enterprise solutions - please correct me if I'm wrong:
- It looks nice for simple entity, but how this would scale with even-not-so-complex object graph?
- Secondly, what about displaying a list of eg. 100 objects in current (newest) state, when each one has to be recreated from many events? Recreating this from events may be super slow there... Should we introduce "standard" repository and store both events and current object in persistence? If so, how this differs from out of the box solutions like Envers?
- EventSourcedUserRepository looks like extreme thread-unsafe code... For example, what if new events were collected between user.getChanges() and user.flushChanges()? You may say that user shouldn't be used in multithreaded environment and new instance should be used instead. But even then, how would you achieve events order in your repository when there are multiple writers? Yes, you may say that this would require some conceptual rewriting which isn't covered in this presentation, but isn't it about?
Anyway idea sounds really interesting and I'd love to see it in real app.
Hi, Thanks for your comments
1) I don't understand the " out the graph " part of the comment - normally you have a one root object which manages the lifecycle of the whole graph. If does not matter if that's a custom entity or Integer :)
2) You are thinking about projections here and you are right. With events it would be slow. That is why in the second part of the talk I am talking about read models and CQRS for querying 100 objects in a specific state. Envers is all about state (so it forgets the reasons between state changes), whereas event sourcing is all about why we change from state A to B.
3) You are right! This is a demo, not production ready in memory hashmap which is not thread-safe :) You might want to implement optimistic locking. Then you are sure that events are in the correct order.
For testing the historic timestamp you shoould use an IClock or somthing of that sort in your code and then mock the times.
Terrible sound quality. Half of my effort goes into discerning sounds and words.
recorded by walkie-talkie :(