Has anyone encountered datom conflicts after restores? I.e. two entities with the same value for a :db/unique attribute.

e.g.

(d/q '[:find ?e ?unique-ident
       :in $ ?a ?v
       :where
       [?e ?a ?v]
       [?a :db/unique ?unique]
       [?unique :db/ident ?unique-ident]]
     (d/db (db/connection))
     :cat.block/key
     "designers22")

->

[[17592187845110 :db.unique/identity]
,[17592189560149 :db.unique/identity]]

@jthomson: can you also return ?a in the :find spec and report that output?

@jthomson: sorry, never mind, i missed that you were passing it in.

@jthomson: what version of Datomic?

i'm pretty sure it's a real conflict, as when I try to retract the entity I get a two datoms conflict error.

datomic-pro "0.9.5130"

restores are a bit funny aren't they? I noticed yesterday that datomic will still do a differential restore even if I've delete-database'd the target db

hm, interesting

FYI in my case it this was due to trying to restore on divergent dbs (the target had some transactions that were not in the source)

which isn't supported at this point.

yeah, that definitely seems like it could get weird

if I really want to guarantee i've got two identical databases after a restore (like if I want my staging env to match prod exactly), I think I'd have to clean out everything related to my target db in the storage layer. does anyone have a decent way to do that in dynamo besides deleting the table? I've got several database in my dynamo table, but the raw data just looks like gibberish to me.

There is no "differential restore"

Restore always starts from an empty database.

I am confused then, the output I see is that most segments are skipped

"Copied 146 segments, skipped 2672 segments." etc.

restore always checks the whole DB. it only copies when necessary

differential backup doesn’t need to check the whole DB

"starts from an empty database" and "only copies when necessary" sound like conflicting statements to me?

you can restore to an existing uri of the same DB (at a different t)

but, as jthomson mentioned above, if you have a divergent DB, restoring to that existing DB is not supported

right, so if I have DBs that have diverged, and I want to resolve that, what do I do?

basically I want to force prod -> staging while ignoring anything from staging that has diverged

restore to a new/blank DB in staging

So I guess this means use a different name? Thinking about it in my case (which was actually the same use case @kbaribeau) I had deleted the old DB but reused the name, thinking this would create a new db.

yup, same issue ^

You need to call bin/datomic gc-deleted-dbs

see the bottom of this page: http://docs.datomic.com/capacity.html

aha! cool

great

yep, different name won't work because db has unique id that will report conflict if you try to restore same db to different name in the same datomic storage (i.e. into the same bucket/table, w/e)

ah yes of course

Datomic 0.9.5186 has been released: https://groups.google.com/forum/#!topic/datomic/IGzjBbHr10E

curious about this, "* Fixed bug in Pull API when using selectors built from strings."

I reported a bug in which a scalar find spec (aka, :find (pull ?e [*]) .) returned an edn string over the rest api that didn't match what you get at the repl

is that what this refers to?

iirc, over the rest api, you would get a map per attr/value pair

okay, I updated datomic, and it appears that it's not yet fixed

also, I was wrong - you get a 2-vector for each attr/value pair

as though you called vec on the correct result