2 ms·

These are all good points but the core of Fowler's article is that the persistence is against the application's object structures directly, with no translation

by zzzeek 15y ago

These are all good points but the core of Fowler's article is that the persistence is against the application's object structures directly, with no translation to relational concepts needed (note I am the author of a very popular object-relational library, so I'm not in any way opposed to object-relational mapping...it's just interesting to see this approach that requires none). That it's stored in memory and is reconstructed against an event log are secondary to this.

zwischenzug 15y ago
Well, that put it much better than the article did. Since the points I've highlighted argue that he's talking about database features I'd call that a database without impedance mismatch, like erlang's Mnesia.
fauigerzigerk 15y ago
Initially he makes it sound like there is no translation into a different model but at the end of the article he takes it all back and for good reason: Also it's important to keep a good decoupling between the events and the model structure itself. It may be tempting to come up with some automatic mapping system that retrospects on the event data and the model, but this couples the events and model together which makes it difficult to migrate the model and still process old events. So, you're right that he doesn't envision a translation to a relational model but it's not just object structures either.
- zzzeek 15y ago
  Right, but the event system in question could be built up nicely in a couple of hours most likely, and the level of "translation" would be minimal compared to OR mapping - no columns/rows/joins/tables/anything else like that. With such an application I'd probably still be writing the events themselves to a relational database for archiving and potentially sending out report-oriented data as well. I'm not sure how all of that would work out re: ultimately the whole app needs to be stored in an RDBMS anyway for various reasons but it seems interesting to try.

by zzzeek 15y ago

zwischenzug 15y ago

Well, that put it much better than the article did. Since the points I've highlighted argue that he's talking about database features I'd call that a database without impedance mismatch, like erlang's Mnesia.

fauigerzigerk 15y ago

Initially he makes it sound like there is no translation into a different model but at the end of the article he takes it all back and for good reason: Also it's important to keep a good decoupling between the events and the model structure itself. It may be tempting to come up with some automatic mapping system that retrospects on the event data and the model, but this couples the events and model together which makes it difficult to migrate the model and still process old events. So, you're right that he doesn't envision a translation to a relational model but it's not just object structures either.

zzzeek 15y ago
Right, but the event system in question could be built up nicely in a couple of hours most likely, and the level of "translation" would be minimal compared to OR mapping - no columns/rows/joins/tables/anything else like that. With such an application I'd probably still be writing the events themselves to a relational database for archiving and potentially sending out report-oriented data as well. I'm not sure how all of that would work out re: ultimately the whole app needs to be stored in an RDBMS anyway for various reasons but it seems interesting to try.