

Fixing Bad Data in Datomic - lauriswtf
http://blog.datomic.com/2014/08/stuff-happens-fixing-bad-data-in-datomic.html

======
solutionyogi
That was a fantastic read. I can't count the number of hours I have wasted
trying to figure out a bug (or trace a problem) in the system because someone
decided to update the data silently. I think this is the kind of database
which should be standard in finance industry. I have been working for
financial companies in NYC for last 8 years and I have yet to see anyone use
this product. Does anyone on HN have used this on a live system?

~~~
danneu
I ported my 7-year-old vBulletin community to a forum I wrote from scratch
with Clojure + Datomic earlier this year.

Datomic was a nice choice since it makes it trivial to expose a post's edit
history. It also makes it easy to query for all the actions a moderator is
responsible for. And if a moderator goes rogue and deletes everything, it's
easy to revert.

~~~
solutionyogi
Thanks for sharing your experience.

How much effort was it? Did you run in to bugs? How is the performance for a
public facing website? How hard was to adopt to this new mindset about
immutable database?

Ever since I started using Git, I have been wondering as to why we don't have
a database product which works like Git. When I read through this fantastic
page on their rationale
([http://www.datomic.com/rationale.html](http://www.datomic.com/rationale.html)),
I was furiously nodding my head in agreement. Their approach makes so much
sense in this day and age where hardware is cheap.

~~~
berns
This may interest you:
[https://github.com/mirage/irmin](https://github.com/mirage/irmin)

~~~
sgrove
I would _love_ to see a comparison of the ideas behind Datomic and Irmin -
they're actually seem quite different, but a blog comparing the two could
really help clear things up and frame the tasks they're both suited for.

------
sargun
I really like the fact that facts are immutable in the Datomic model. It
actually makes it easier to reason about eventually consistent, because you
can rely on causal consistency between facts. Eventually consistent systems
can give you durability, isolation, and atomicity, but it's typically hard to
reason about, because the interface that's given to the user is some sort of
multi-value, vector-clock tracked thing, and it's hard to reason about.

Datomic can manage a commit protocol under the hood, and deal with causality
tracking without requiring the developer to "get dirty." It's query language
is declarative, and doesn't provide the same implicit guarantees that SQL
queries need.

~~~
mdavidn
Datomic is not an eventually consistent system. All writes pass through a
single "transactor," which serializes transactions and provides the same ACID
guarantees as a traditional SQL database.

~~~
sargun
But, the data storage can be in a AP system, allowing better stories around
data availability.

~~~
dantiberian
The Datomic docs at
[http://docs.datomic.com/acid.html](http://docs.datomic.com/acid.html)
describe it's ACID properties quite well.

> Another way to understand this is to consider the failure mode introduced by
> an eventually consistent node that is not up-to-date yet. Datomic will
> always see a correct log pointer, which was placed via conditional put. If
> some of the tree nodes are not yet visible underneath that pointer, Datomic
> is consistent but partially unavailable, and will become fully available
> when eventually happens.

------
ds_
Are there any promising open source alternatives with similar philosophies to
datomic?

