4 ms·

SQL databases also do this. They have events called 'SQL statements' which are written to a 'journal' and applied to the domain which resides in the 'tables' of

SQL databases also do this. They have events called 'SQL statements' which are written to a 'journal' and applied to the domain which resides in the 'tables' of the database :)

Tuna-Fish 13y ago
You seem to not understand the point. SQL databases don't count because these mechanisms are not visible, and the programming model is changing data in place. No-one really cares how DB's are implemented under the hood, we just care about the programming model. (And speed, CAP, ACID, etc...)
- strictfp 13y ago
  I do get the point, in fact I'm building such an app right now, but my statement is still true and I find that quite amusing.
  - jimbokun 13y ago
    Given the underlying architecture of most relational databases, is it realistically possible to do "point in time queries", without requiring playing back the entire log history into a clean database up to the point in time you want? That's not going to be very efficient. I've only seen SQL logs presented as solutions to replication and disaster recovery, not point in time functionality. What I'm getting at, is it even possible in principle to expose part of the inner workings of some relational database systems to get this kind of capability?
    - strictfp 13y ago
      Snapshotting and log replay should be fairly straightforward, if you save all sql statements in their entirety. Snapshots would stop the world, which might pose a problem, but I presume this is no different to other event sourcing solutions. Given the concurrency of a db, I'm also not sure that there's a strict ordering of all incoming statements. Edit: Seems like at least Oracle is already doing this: http://en.wikipedia.org/wiki/Redo_log http://en.wikipedia.org/wiki/Redo_log
    - twic 13y ago
      Not only is this possible, Oracle has had exactly that feature since 2002: http://docs.oracle.com/cd/E11882_01/appdev.112/e17125/adfns_flashback.htm#i1008579 http://docs.oracle.com/cd/E11882_01/appdev.112/e17125/adfns_...

SQL databases also do this. They have events called 'SQL statements' which are written to a 'journal' and applied to the domain which resides in the 'tables' of the database :)

Tuna-Fish 13y ago

You seem to not understand the point. SQL databases don't count because these mechanisms are not visible, and the programming model is changing data in place. No-one really cares how DB's are implemented under the hood, we just care about the programming model. (And speed, CAP, ACID, etc...)

strictfp 13y ago
I do get the point, in fact I'm building such an app right now, but my statement is still true and I find that quite amusing.
- jimbokun 13y ago
  Given the underlying architecture of most relational databases, is it realistically possible to do "point in time queries", without requiring playing back the entire log history into a clean database up to the point in time you want? That's not going to be very efficient. I've only seen SQL logs presented as solutions to replication and disaster recovery, not point in time functionality. What I'm getting at, is it even possible in principle to expose part of the inner workings of some relational database systems to get this kind of capability?
  - strictfp 13y ago
    Snapshotting and log replay should be fairly straightforward, if you save all sql statements in their entirety. Snapshots would stop the world, which might pose a problem, but I presume this is no different to other event sourcing solutions. Given the concurrency of a db, I'm also not sure that there's a strict ordering of all incoming statements. Edit: Seems like at least Oracle is already doing this: http://en.wikipedia.org/wiki/Redo_log http://en.wikipedia.org/wiki/Redo_log
  - twic 13y ago
    Not only is this possible, Oracle has had exactly that feature since 2002: http://docs.oracle.com/cd/E11882_01/appdev.112/e17125/adfns_flashback.htm#i1008579 http://docs.oracle.com/cd/E11882_01/appdev.112/e17125/adfns_...