Fork me on GitHub
#datomic
<
2020-09-02
>
souenzzo13:09:21

https://docs.datomic.com/on-prem/clojure/index.html#datomic.api/transact This doc string need a update it says "If the transaction times out, the call to transact itself will throw a RuntimeException" I got "clojure.lang.ExceptionInfo: :db.error/transaction-timeout Transaction timed out."

Alex Miller (Clojure team)13:09:42

ExceptionInfo is a RuntimeException

joshkh14:09:38

i remember once having to run d/administer-system as part of a Datomic Cloud upgrade, but i can't find any historical mention of it in the release notes. is that something we should be doing regularly when upgrading?

favila16:09:09

It’s only purpose right now is to upgrade schema on a db created with a version that predates the various features that introduced new schema. so you only run it once

favila16:09:19

these are on-prem docs, but the same applies

favila16:09:26

I can’t find equivalent cloud docs

favila16:09:10

so you should definitely not be running it regularly

nando20:09:44

Beginner here. To "update" an entity, must the entity have a :db.unique/identity attribute? Or is there a way to rely on the datomic assigned entity id for this? https://docs.datomic.com/cloud/transactions/transaction-processing.html#unique-identities

favila20:09:36

It may help to think backwards. All transactions must eventually fully expand to a set of [:db/add e a v] or [:db/retract e a v] operations. Maps are a syntax sugar for :db/add s

favila20:09:40

the sugar is either 1) Your map has an explicit :db/id with an entity identifier (entity id, lookup-ref, or ident) 2) your map has a tempid, or 3) your map has no :db/id at all, so it gets a tempid automatically

favila20:09:08

later, after full expansion, some “e”s will be entity ids and some will still be tempids

favila20:09:14

if an e is a tempid and there’s an assertion that mentions a unique-identity attribute that already exists, the tempid can be substituted for the already-existing id

favila20:09:31

otherwise the tempid will be replaced with a newly-minted id

nando20:09:38

So I can use the entity id of an entity in :db/id to update that entity?

favila20:09:48

so, stepping back, you can do this {:db/id 1234 :foo "bar"} or {:db/id [:unique-attr "value"] :foo "bar"} or {:db/id :ident-value :foo "bar"} if you want to be explicit about what entity you want to assert on

favila20:09:34

this “upsertion” case should really be the less common case, and only matters if you want create-or-update behavior.

favila20:09:26

that said, you should still use a unique attribute of some kind (not necessarily unique-identity--unique-value is ok) to identify your entities rather than raw entity ids

nando20:09:22

Ok, so generally speaking, I should add UUID attributes to all entities in my schema, unless some other attribute will be unique. Correct?

favila20:09:10

all entities that need to be identifiable from outside datomic should have a unique attribute

favila20:09:59

sometimes you don’t need this. e.g. many isComponent entities have no meaning aside from their “parent” entity, and it’s often ok to not give these unique ids

favila20:09:29

the functions that construct txs that manipuate them will have a proper identifier for the parent and will find them that way

nando20:09:17

Ok, thanks very much for your help.

👍 6
favila20:09:35

glad to help, sorry if that was long-winded

Yuriy Zaytsev20:09:13

Hi there. I have a question about analytics. I want to have separate metaschemas for development and for production. What is the best way to do it? If I have for example 2 metaschemas in which order it will be applied?