Since the recommended transactor upgrade approach is to stand up the new version and then kill the old ones (letting the new ones fail over), is there a way to do that without losing the ability to transact data during the failover delay? Or do you just have to schedule a bit of downtime for all your systems?

Got my answer in a support ticket. The key was reading and fully understanding this: http://docs.datomic.com/ha.html#peer-recovery-time. TL;DR is you either design your whole system to tolerate this or yes, you need scheduled downtime.

hey all, the schema documentation says "You can also retract optional schema attributes with :db.alter/attribute.” Does anyone know how to do this? There don’t appear to be any examples.

@ethangracer: This section of the docs: http://docs.datomic.com/schema.html#schema-alteration discusses altering schema. Further down in this section there is an example that uses retraction to ‘unset’ isComponent

@marshall: thanks, i’m looking for something a bit different. I think by optional schema attributes they mean things like isComponent. I want to take one attribute name and effectively ‘merge’ it with another. So I have :category/name that I want to now be equivalent to :tag/name. So I was hoping to retract the :category/name attribute, and either replace it with :tag/name or make new entries on the entity called :tag/name

The key point there is “optional schema attributes” :db/ident is a required attribute

that same page has a table listing the optional attributes that can be altered

I was afraid you were gonna say that 😄

is removing the uniqueness attribute a bad idea?

http://docs.datomic.com/schema.html#renaming-an-identity There is a way to ‘rename’ an attribute

so, :db/ident can be renamed, it can’t be retracted.

yeah I saw that, unfortunately I want to rename it to an attribute name that already exists

so we’re getting a :db.err/unique-conflict

ah, in that case you’ll want to transition your data from one attribute to the other

assuming the new data don’t violate uniqueness constraints

oh boy. alright, thanks for the help!

Note: please backup your DB before any schema alteration

and if at all possible, do the alteration in staging or dev prior to rolling it out in prod

thanks, those are both absolutely happening!

@marshall: so, am I right in thinking that it’s impossible to remove the old name from the schema? but from now on, consistently use the new one?

That's correct. You can't remove schema elements

Well! Far as I can tell, Aleph (latest) and Datomic (latest): no go in the same JVM: fundamentally incompatible versions of netty-all.

@zentrope I'm looking into the compatibility issue and potential solutions I'll update on the Google group thread when I have something to report

Okay. It’s not that big of a deal (other than just worrisome jar-hell stuff). But if a simple tweak on Datomic would make everything magically work, I’d not turn it away! ;)

@marshall: Meanwhile, I’ll see what it’s like to use httpkit stuff again.