Fork me on GitHub
#datomic
<
2016-07-11
>
cap10morgan16:07:21

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?

cap10morgan17:07:14

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.

ethangracer20:07:39

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.

marshall21:07:53

@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

ethangracer21:07:52

@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

marshall21:07:46

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

marshall21:07:19

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

ethangracer21:07:19

I was afraid you were gonna say that 😄

ethangracer21:07:18

is removing the uniqueness attribute a bad idea?

marshall21:07:04

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

ethangracer21:07:19

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

ethangracer21:07:29

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

marshall21:07:46

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

marshall21:07:00

assuming the new data don’t violate uniqueness constraints

ethangracer21:07:49

oh boy. alright, thanks for the help!

marshall21:07:16

Note: please backup your DB before any schema alteration

marshall21:07:33

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

ethangracer21:07:41

thanks, those are both absolutely happening!

ethangracer21:07:09

@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?

marshall21:07:37

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

zentrope23:07:11

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

marshall23:07:12

@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

zentrope23:07:06

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! ;)

zentrope23:07:45

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