Clojurians Log v2

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

ExceptionInfo is a RuntimeException

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

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

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

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.

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?

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

https://docs.datomic.com/on-prem/deployment.html#upgrading-schema

these are on-prem docs, but the same applies

I can’t find equivalent cloud docs

so you should definitely not be running it regularly

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.

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

Ok, thanks very much for your help.

glad to help, sorry if that was long-winded