Fork me on GitHub
#datomic
<
2017-06-24
>
eoliphant02:06:04

Hi, how do folks handle database migration, walking schema changes through enviroments, etc with Datomic? I’ve hand-rolled something using conformity, but was just wondering if there’s a “Datomic way”. After reading this: http://blog.datomic.com/2017/01/the-ten-rules-of-schema-growth.html, Item 3 speaks to your DB being the source of truth, etc. But it’s not entirely clear in terms of taking that truth and walking it forward. Would it be something like dumping the schema entities, versioning those then applying to subsequent environments?

eoliphant13:06:53

ah thanks @val_waeselynck checking it out

daemianmack14:06:29

eoliphant: FWIW conformity has always been more than sufficient for my personal/client projects.

daemianmack14:06:24

i wouldn't interpret Item 3 of that blogpost to suggest adding machinery around versioning datoms. my read of it is more an observation that, working with a large/shared database, not to assume my local software description of the database is necessarily a trustworthy representation of the actual state of that database, and to defensively assume drift.

eoliphant19:06:13

Sure @daemianmack I can see that too, but it did seem , to me at least, a little confusing around what that means from a best practice, etc perspective

eoliphant19:06:33

I have a question about isComponent, well I think I know that answer already based on my experimentation lol, but I just want to confirm. It appears to be ‘recursively greedy’ in that if I do a retractEntity, and isComponent tagged attribute will have it’s refs retracted, and refs that those refs, ref, etc? I’m playing around with a dynamic schema/forms deal, so I say define field types, then I define a form type. The form has a ref to a collection of field defs, that include some form specific stuff (am I optional, etc) and a ref back to the field type (I’m a string, etc), so my :form/fields was tagged as a component and after a delete of a form type the entire graph had been retracted. Is there any way to short circuit this? such that say subsequent non-component refs are left alone?

favila20:06:11

An entity reachable via an IsComponent attr should only ever be reachable via one datom assertion

favila20:06:22

Sounds like in your example the ref from field to field type should not be via an iscomponent attr

favila20:06:06

Practical rules for use of isComponent (but not enforced by datomic): an entity reachable via an isComponent attr is wholly owned by its parent, and unreachable except through the parent, and the parent has only one reference to it

eoliphant01:06:56

yeah, I need to recheck it, but I’m pretty certain my field -> fieldtype wasn’t that’s what threw me. But will check it again

daemianmack20:06:46

eoliphant: i agree, it's a bit philosophical, and it's not clear what practical steps might be in sync