it is possible. https://docs.datomic.com/on-prem/schema/schema-change.html

if you are on on-prem and the attribute does not have a value index yet, you need to add one first so it can verify uniqness

cloud has a value-index on everything already

https://docs.datomic.com/on-prem/schema/schema-change.html#adding-avet-index that should be good enough?

yes. Note this section https://docs.datomic.com/on-prem/schema/schema-change.html#altering-attribute-to-unique > In order to add a unique constraint to an attribute, Datomic must already be maintaining an AVET index on the attribute, or the attribute must have never had any values asserted. Furthemore, if there are values present for that attribute, they must be unique in the set of current assertions. If either of these constraints are not met, the alteration will not be accepted and the transaction will fail.

(I”m assuming through all of this that you are using on-prem--if you are using cloud you may have a different problem)

i'm on prem

for reference, for datomic-pro (and the other deps) this just works: wget --http-user=$DATOMIC_REPO_USER --http-password=$DATOMIC_REPO_PASS

context: we need to bump the postgresql adapter to something recent so we can use modern password strategies (iirc). We run datomic on Nomad (i.e. in a docker container) and built our own. We need to include some jars in the installation anyway for prometheus metrics and custom database functions. currently we fetch a datomic installation, manually fetch a bunch of jars to update and replace them in ./lib. We figured we could just write a pom.xml to ‘bump’ the postgres dependencies and include our own, and simply switch to jib to built the Dockerfile. But we hit a snag here because we can’t actually fetch the datomic-transctor-pro jar.

how can you confidently write a pom.xml that accurately reflects everything a datomic transactor needs?

IMO patching lib is the only safe thing to do

(It’s what we do, then we stash the updated zip on s3)

and this is even being 90% sure that most of the bytes in lib are just transient-deps of requiring the entire aws sdk and are not used.

I figured id use the pom that comes with the transactor 😅, its bundled

And refer to it in my own pom, using managed deps to make sure i get the deps i want

Are you referring to the pom.xml in the root of the zip? That appears to be for the client (note the artifactId).

The pom inside the transactor-jar (under meta INF)

I just hoped it would be available to pull from my.datomic 😁, orherwise well have to do the unpacking and lib patching, but it started to grow too big for my liking,

Now, I'm sure Cognitect will tell me I forgot something obvious... 😬

I think this is worth raising in the official forum

forum or ask?

ask, I think

You asked, https://ask.datomic.com/index.php/790/is-there-disparity-in-d-pull-between-dev-local-and-client-api. Thanks @U050ECB92. :)

I think I see what we did there. An org mode error. The section is missing the following bullet points:

The ${Peer} server is a JVM process that provides an interface for the Datomic Client library.

- Accepts queries and ${transaction}s from Datomic Clients
- Submits transactions to, and accepts changes from, the ${transactor}
- Provides data access, caching, and ${query} capability to connected Clients, reading from the ${storage service} as needed

I will get this updated once I untangle how it happened.

Thank you for the report!

Yup 👍

I saw your first question before you deleted it. I just wanted to add that while there is currently no way (api or other tooling) to heat up a new cache you can use a shared memcached for transactor and multiple peers. This pattern enables new peers to have some relevant information ready in the shared cache. Particularly useful if you have a dedicated peer walking the indexes or a reporting type peer process that might touch all data. I am happy to answer more questions about caching in Datomic if you have a need. <mailto:[email protected]|[email protected]> or DM me.