Hacker News Reader

Comment by ryanbrush | Hacker News Reader

Whether through Datomic or something else, it seems like some version of "database-as-a-value" (as described by Rich Hickey) is bound to happen. We're keeping immutable version histories of as much as our hardware and systems will allow, from source code management through other types of media. Why in the world wouldn't we do this with our data if we could?

It'll be interesting to see how this plays out. Widespread adoption of technology tends to follow a path of least resistance. Does Datomic offer a simple enough path to pull many people over? I also know many of us have a preference for building on open source systems; will this be an obstacle for Datomic?

View on HN

Take a look at Event Sourcing, commonly used with CQRS. The approach is indeed to store data as change-events in an event-store (which could by a SQL database or NoSQL store, that depends on your needs) and then built one or more views (separate databases, Lucene indexes, files, anything really) to service the type of requests that the application handles.

For an example of CQRS with Event Sourcing in Java: http://axonframework.org

There is also http://geteventstore.com/ - an immutable event database by one of the main CQRS aficionados - Greg Young. BTW, clustered HA setup has been opensourced very recently.

Really solid and fun to work with.

And there is also the old-school http://prevayler.org/ :)

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 :)

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...)

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.

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?

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

Not only is this possible, Oracle has had exactly that feature since 2002:

http://docs.oracle.com/cd/E11882_01/appdev.112/e17125/adfns_...

Reply on news.ycombinator.com