Duplicate Facts?

General
1

Let’s say I have an entity of [name][height][favorite color] and I store [“Bob”][73][“blue”] and then Bob (who has an ID of “23”, let’s say). changes his favorite color to “green”. The way my code is set up, I transact [23][“Bob”][73][“green”].

The only fact that’s actually changed is that favorite color has gone from “blue” to “green”. I’m guessing Datomic must know this and only make that change, not add the facts about “Bob” and “73” again.

If my assumption is correct, it doesn’t matter from a data integrity standpoint whether you pass facts multiple times, though perhaps stylistically (and for efficiency) one wouldn’t?

EDIT: Another, perhaps less egregious example would be an “active” field. Let’s say a user becomes “active” when they first sign in. You could assert in the code that whenever a user signed in, you transacted a “true” to their “Active” attribute. Otherwise, you’d have first ask whether the user was active and only set them to true if they weren’t already.

So, do we check first, or do we just assert knowing Datomic will not repeat facts?

2

Datomic does redundancy elimination for all datoms in a transaction. As long as the E, A, and V positions of a datom are the same as one that is already in the database, the redundant datom will not be reasserted.

3

Marshall what is the purpose of redundancy elimination? Why not just reassert the facts? (I think I am missing something)

4

Redundancy elimination makes for cheap idempotency. Otherwise you’d either end up making a huge DB with lots of redundant data or you’d have to handle “check then assert” everywhere in your application.

5

I figured that had to be the case.

I’m still sometimes thinking of this as being a record, but a schema really only determines what attributes can be asserted about an entity, and the entity itself is just a number.