Ask questions on the official Q&A site at https://ask.datomic.com!
jaret 2020-09-10T15:10:02.380Z

Hey @john.leidegren, Marshall tasked me with looking into this and I wanted to clarify that this is indeed intended behavior and not related to the fix Marshall described. You already have the rough reason here: > Yeah, the application of transactions is unordered, so if you say add twice for the same attribute of cardinality one it cannot know which one you meant so it rejects the transaction. You cannot transact on the same datom twice and have it mean separate things in the same transaction. You have to split the transactions up to retract the entity then assert the new identity. Ultimately what you're doing here is cleaning up a modeling decision and in addition to separating your retraction and add transactions you could alternatively model a new identity and use that identity going forward, preserving the initial decision.

jaret 2020-09-10T15:10:36.380200Z

I know you were already past this problem, but I hope that clears things up.

davewo 2020-09-10T18:23:08.382200Z

I am trying to update schema to add uniqueness to an attribute like so:

[{:db/id        :owsy/dot-number
  :db/unique    :db.unique/identity}]
but I get the following error:
clojure.lang.ExceptionInfo: java.lang.IllegalArgumentException: :db.error/invalid-alter-attribute Error: {:db/error :db.error/unique-without-index, :attribute :owsy/dot-number} {:succeeded [{:norm-name :V20200901/clearfork-last-funded-date-SNAPSHOT, :tx-index 0, :tx-result {:db-before datomic.db.Db@ad33f60, :db-after datomic.db.Db@d3dfdde3, :tx-data [#datom[13194140022304 50 #inst "2020-09-10T18:17:17.664-00:00" 13194140022304 true] #datom[13194140022304 72 :V20200901/clearfork-last-funded-date-SNAPSHOT 13194140022304 true] #datom[13194140022304 73 0 13194140022304 true] #datom[456 44 true 13194140022304 true] #datom[0 19 456 13194140022304 true]], :tempids {-9223354444669732589 13194140022304}}}], :failed {:norm-name :V20200901/clearfork-last-funded-date-SNAPSHOT, :tx-index 1, :reason "java.lang.IllegalArgumentException: :db.error/invalid-alter-attribute Error: {:db/error :db.error/unique-without-index, :attribute :owsy/dot-number}"}}
This is confusing because I thought that adding :db/unique would also set :db/index true

ghadi 2020-09-10T18:26:42.383300Z

@davewo I think it's saying that your data isn't already unique :db.error/unique-without-index so you can't add a uniqueness constraint

davewo 2020-09-10T18:32:41.384Z

https://docs.datomic.com/on-prem/schema.html#schema-alteration "In order to add :db/unique, you must first have an AVET index including that attribute."

davewo 2020-09-10T18:32:51.384300Z

that seems more in line with the error message

ghadi 2020-09-10T18:33:36.384700Z

ah yeah

ghadi 2020-09-10T18:33:54.385300Z

good catch!

davewo 2020-09-10T18:34:28.386Z

and because those indexes are added asynch, adding the :db/index in the same tx doesn't work (which I tried)


Is there anyway to clone an in memory peer connection? Lets say I want to transact a large schema and then be able to make clones of it at that point for testing purposes and not incur the schema transaction cost each time?

kenny 2020-09-10T21:36:20.389700Z

Perhaps https://github.com/vvvvalvalval/datomock?


@kenny cool, I’ve run across this lib a couple times but I guess it never sunk in what usecase it solved 😄

Joe Lane 2020-09-10T22:39:29.391400Z

@colinkahn Have you considered using the new dev-local database? Copying a database is literally cp my-db the-copy-of-my-db


I just saw that today. I’ve been using https://github.com/ComputeSoftware/datomic-client-memdb for testing, but they’re saying to switch over to dev-local. But at first glance seems like it writes to disk which I don’t need for tests.