This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-02-12
Channels
- # aleph (22)
- # aws (7)
- # babashka (17)
- # beginners (69)
- # chlorine-clover (9)
- # cider (2)
- # clj-kondo (3)
- # cljdoc (30)
- # clojure (113)
- # clojure-dev (30)
- # clojure-europe (11)
- # clojure-italy (2)
- # clojure-nl (16)
- # clojure-spec (1)
- # clojure-sweden (3)
- # clojure-uk (17)
- # clojurescript (77)
- # cryogen (12)
- # data-science (5)
- # datomic (27)
- # duct (2)
- # emacs (37)
- # fulcro (24)
- # graphql (2)
- # kaocha (1)
- # lambdaisland (27)
- # leiningen (4)
- # off-topic (15)
- # onyx (1)
- # other-lisps (3)
- # re-frame (94)
- # reagent (2)
- # reitit (20)
- # ring (1)
- # shadow-cljs (66)
- # spacemacs (5)
- # sql (59)
- # tools-deps (140)
- # vim (1)
- # xtdb (17)
Should the order matter at the installation of tuple attributes? This works
[{:db/ident :reg/course
:db/valueType :db.type/ref
:db/cardinality :db.cardinality/one}
{:db/ident :reg/semester
:db/valueType :db.type/ref
:db/cardinality :db.cardinality/one}
{:db/ident :reg/student
:db/valueType :db.type/ref
:db/cardinality :db.cardinality/one}
{:db/ident :reg/semester+course+student
:db/valueType :db.type/tuple
:db/tupleAttrs [:reg/course :reg/semester :reg/student]
:db/cardinality :db.cardinality/one
:db/unique :db.unique/identity}]
While this doesn't
[{:db/ident :reg/semester+course+student
:db/valueType :db.type/tuple
:db/tupleAttrs [:reg/course :reg/semester :reg/student]
:db/cardinality :db.cardinality/one
:db/unique :db.unique/identity}
{:db/ident :reg/course
:db/valueType :db.type/ref
:db/cardinality :db.cardinality/one}
{:db/ident :reg/semester
:db/valueType :db.type/ref
:db/cardinality :db.cardinality/one}
{:db/ident :reg/student
:db/valueType :db.type/ref
:db/cardinality :db.cardinality/one}]
@pfeodrippe Yes, we are aware of that behavior, we are investigating whether it can be changed to be order insensitive
@U05120CBV thank you!
if you go to http://datomic.com and click on Products or peruse some docs, you can see differences between the two
there's also some comparison here https://docs.datomic.com/on-prem/moving-to-cloud.html
For non-breaking schema updates, is it fine to re-transact my entire apps schema idents every time I start an app instance? Could this cause any issues down the road?
1) don't do anything except non-breaking schema growth 2) yeah it's unnecessary and can probably cause issues, especially when you have many app instances
Right, everything is non-breaking, I just put that qualifier in there for clarification. Didn't know if datomic only transacted changes anyway, I guess I'll have to write some sort of diffing engine, manually syncing the schema on each change doesn't work for my use case. Thank you.
Got it, yeah I guess I only need to diff on the top level items, no need for a deeper tree diff update. Thanks again!
I mean for example.. updating an existing entity from non-component entity to component entity, I can just re-transact the entire ident, instead of comparing all the individual db entity properties and updating only those that changed
yeah, understood. Another approach is to transact collections of schema and mark in the tx metadata something identifying the collection itself
that way one collection can make schema, then a later collection can update some part of it
that way instead of ensuring that attr :patient/id
exists, you can ensure that 20200212-patient-stuff.edn
is in the database
Got it, yeah using more traditional migration. I do like the first approach however, since all changes to Datomic are non-breaking anyway, I can use a declarative format agnostic to datomic for my schema, then generate the datomic idents, as well as schemas for other purposes ex: GraphQL from that source. It's been super helpful for rapidly building out internal apis without the need to duplicate schema information everywhere.