Fork me on GitHub
#datomic
<
2017-03-27
>
juliobarros15:03:40

Hi, I’m looking for a way to manage ‘migrations’ with Datomic. I found https://github.com/rkneufeld/conformity by Ryan Kneufeld. Is this still a good way to go or do people have different/better strategies? Thanks in advance.

juliobarros16:03:40

@marshall yeah but I still need a way to manage growth. I didn’t necessarily mean changing or breaking the schema.

pesterhazy16:03:27

@juliobarros I prefer a simple .clj file with migrations

pesterhazy16:03:36

I do that for SQL as well as for Datomic

pesterhazy16:03:12

migration frameworks are frequently overengineered

pesterhazy16:03:34

besides the Datomic schema is often idempotent

pesterhazy16:03:44

I suspect re-asserting the schema on each peer start would not be harmful

juliobarros16:03:19

Thanks @pesterhazy … I haven’t kept up with Datomic lately but I thought I remembered the guideline to not reassert datoms (including schema). Anyway, conformity looks lightweight enough so I’ll go with that. Thanks again.

brett20:03:43

Hi, I’m trying to load some data into datomic. The entities I’m trying to load have a reference to entities already in the db. Do I have to look up those entity reference before hand, or is there a way to do it all in one go.

brett20:03:40

Existing: {:db/id 1234 :location “New York”} New {:name “John” :location <entity ref>}

brett20:03:41

Can you do this {:name “John” :location [:find e? :where [e? :location “New York]]}

marshall20:03:29

you’ll need a unique attribute on the ‘target'

marshall20:03:48

i.e. if your location entity has a :location/name attribute that is db.unique/identity

marshall20:03:01

you could use [:location/name “New York”]

marshall20:03:09

instead of having to look up the entity ID

brett20:03:47

ok, I was looking at that, but thought it was only for updating same entity. Let me give that a try. thx.

marshall20:03:48

^this would be the preferred approach in fact - generally you should avoid using entity IDs directly