In other words, just use git...
http://www.wired.com/2014/09/most-code-is-an-ugly-mess-heres-how-to-make-it-beautiful
Is it just me, or does anyone else get source control vibes from this "event sourcing" design pattern?
Is it just me, or does anyone else get source control vibes from this "event sourcing" design pattern?
Where I worked this summer, they had database tables where an update didn't really update. What they did was instead set a field to indicate that this row was now historical, and then add a new row that was a copy of this old row with whatever rows updated.
So let's say you change one field in a row, what really happens is an entirely new row gets created with that one field changed, and the old row is marked as historical. Each row had a 'hidden' timestamp field that was used to see when changes were made. These tables were massive too; 50+ columns was the norm, so these copies weren't light.
When I first found out about this I was just blown away. I mean, is there no better way to keep track of changes than just blowing storage away?
So let's say you change one field in a row, what really happens is an entirely new row gets created with that one field changed, and the old row is marked as historical. Each row had a 'hidden' timestamp field that was used to see when changes were made. These tables were massive too; 50+ columns was the norm, so these copies weren't light.
When I first found out about this I was just blown away. I mean, is there no better way to keep track of changes than just blowing storage away?
I actually think the event sourcing idea is a really clever solution to this problem; I just think it's reinventing source control.
I suspect there's some discrepancy between how awed I feel and how awed the author expected me to feel. The revelation that if I want to track the various states of an object I need to save those states (or the state transitions) hasn't caused me to reach satori.
Let's just hope he doesn't realize that if the initial state is not a contant he can use a list of state transitions as a form of template, or his brain might explore.
Let's just hope he doesn't realize that if the initial state is not a contant he can use a list of state transitions as a form of template, or his brain might explore.
I think it's actually not a bad idea. What I'm doing now involves saving state, reloading state, and synchronizing state between client and server. But the full state the of the program I am finding is very complex, and not only that, but every time a new feature is added, it needs to be incorporated into this state management system. Besides having to store a lot of details, and writing methods to recreate these details, there is another big problem. The person who works on this after me that tries to add new features will inevitably screw it up, or not have the fortitude to change anything other than what's necessary to get the feature working. So this idea does have some merit in solving my problem. At least it would make a lot of things a lot easier for me. There are some issues though. Processing events in my application takes time. There is no way you can really replay all of the events. In my situation it wouldn't even make sense to. I would have to have a sort of hybrid approach, keep track of the states of some things and use event sourcing to manage the state of other aspects. But then it becomes possibly more complex anyways because now state management is divided. Now I have the same problem, maybe made a little easier, along with another dependency. And it's hard to get around the inherit inefficiency. But the problem it tries to solve is significant. I'm not sure it will work for me, but it's food for thought.
You only have to replay events which are new compared to your current state. Additionally you could sync events as they happened and notify the user if an event conflicts with their current work.
Topic archived. No new replies allowed.