Ask questions on the official Q&A site at https://ask.datomic.com!
souenzzo 2020-09-02T13:16:21.189200Z

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."

alexmiller 2020-09-02T13:20:42.189400Z

ExceptionInfo is a RuntimeException

stuarthalloway 2020-09-02T14:15:07.189500Z

@seancorfield @kenny we certainly intend for people to use dev-local in CI (and do so ourselves.)

stuarthalloway 2020-09-02T14:16:24.189700Z

We have always maintained a private maven repo for our CI system, and in that world it doesn't matter where a dep comes from. (The time and effort is in reviewing/approving a lib, not in copying it into S3.)

stuarthalloway 2020-09-02T14:17:12.189900Z

That said, we want to meet our users where they are, not where we are, so we are considering ways to make this better.

stuarthalloway 2020-09-02T14:19:07.190100Z

It depends on what you are trying to do. Getting multiple asOf points against a particular entity may lose against walking the entire history. See also https://docs.datomic.com/cloud/time/filters.html#filter-or-log.

joshkh 2020-09-02T14:42:38.191900Z

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?

favila 2020-09-02T16:00:09.192700Z

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

favila 2020-09-02T16:00:19.193100Z

these are on-prem docs, but the same applies

favila 2020-09-02T16:00:26.193300Z

I can’t find equivalent cloud docs

favila 2020-09-02T16:01:10.193500Z

so you should definitely not be running it regularly

seancorfield 2020-09-02T16:29:11.193900Z

We used to run an instance of Apache Archiva for CI but it was a pain because it would randomly lock up/crash, and we only did it because Clojars wasn't always reliable. Since Clojars got a CDN, we pulled the plug on Archiva, and for the only custom dependency we have left, we use use a :local/root dependency to the JAR (and we keep versions of the JAR in a separate third-party repo under git because it's a lot easier than needing to worry about some external repo and making sure it's always available). Having to maintain a separate Maven-style repo just for a couple of JARs or deal with custom upload code and S3 is an overhead a lot of people don't want. Like I said on the forum, the current works for me and could work for us, because of how we have things setup, but I also have sympathy with other folks who feel this doesn't scale to larger teams or larger CI pipelines, in its current form.

nando 2020-09-02T20:14:44.196400Z

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

favila 2020-09-02T20:23:36.196500Z

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

favila 2020-09-02T20:26:40.196700Z

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

favila 2020-09-02T20:27:08.196900Z

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

Yuriy Zaytsev 2020-09-02T20:28:13.197400Z

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?

favila 2020-09-02T20:28:14.197500Z

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

favila 2020-09-02T20:28:31.197700Z

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

nando 2020-09-02T20:30:38.198Z

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

favila 2020-09-02T20:30:48.198200Z

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

favila 2020-09-02T20:31:34.198400Z

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

favila 2020-09-02T20:32:26.198600Z

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

nando 2020-09-02T20:34:22.198800Z

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

favila 2020-09-02T20:35:10.199100Z

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

favila 2020-09-02T20:35:59.199400Z

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

favila 2020-09-02T20:37:29.199600Z

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

nando 2020-09-02T20:38:17.199800Z

Ok, thanks very much for your help.

favila 2020-09-02T20:40:35.200100Z

glad to help, sorry if that was long-winded