This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-12
Channels
- # admin-announcements (2)
- # aleph (2)
- # arachne (16)
- # beginners (33)
- # boot (20)
- # bristol-clojurians (6)
- # capetown (4)
- # cider (50)
- # clojure (74)
- # clojure-austin (4)
- # clojure-canada (1)
- # clojure-china (2)
- # clojure-czech (1)
- # clojure-greece (1)
- # clojure-poland (4)
- # clojure-quebec (5)
- # clojure-russia (5)
- # clojure-spec (34)
- # clojure-uk (45)
- # clojurescript (131)
- # cursive (4)
- # datascript (2)
- # datomic (9)
- # editors (2)
- # emacs (2)
- # hoplon (173)
- # jobs (5)
- # lein-figwheel (3)
- # leiningen (1)
- # off-topic (1)
- # om (44)
- # onyx (8)
- # proton (10)
- # re-frame (81)
- # reagent (23)
- # untangled (57)
- # vim (2)
- # yada (8)
@zentrope, @marshall I ran into the same issue with aleph and latest datomic. current solution for me: going back to datomic 0.9.5372
Is there any potential harm in transacting the same schema attributes multiple times?
for example, when doing naive migrations of new attributes, not worrying about filtering out attributes already in the db
@pheuter: If a given transaction has no ‘novel’ datoms, it will create an empty transaction entity in the log. Otherwise, no, re-asserted datoms are ignored
In general I wouldn’t do it all the time (i.e. on startup), but occasionally (as in part of a migration) shouldn’t be a big deal
@pheuter: You've probably seen this, but just in case https://github.com/rkneufeld/conformity
this is great, thanks guys! yeah, this isn’t an on-startup thing as much as one-off migrations of schema changes
conformity seems to be heavily inspired by the day-of-datomic code for migrations, that is worth checking out as well: https://github.com/Datomic/day-of-datomic/blob/master/src/datomic/samples/schema.clj