This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-02-27
Channels
- # announcements (8)
- # architecture (3)
- # aws (18)
- # beginners (96)
- # bristol-clojurians (3)
- # calva (15)
- # cider (7)
- # clj-kondo (8)
- # clojure (135)
- # clojure-denmark (1)
- # clojure-dev (14)
- # clojure-europe (37)
- # clojure-italy (9)
- # clojure-nl (14)
- # clojure-sanfrancisco (1)
- # clojure-spec (1)
- # clojure-uk (54)
- # clojurescript (27)
- # core-async (243)
- # cursive (28)
- # data-science (6)
- # datomic (33)
- # fulcro (25)
- # graalvm (24)
- # hoplon (2)
- # instaparse (12)
- # jackdaw (1)
- # java (21)
- # juxt (12)
- # meander (10)
- # nyc (4)
- # off-topic (6)
- # om (3)
- # pathom (17)
- # perun (1)
- # re-frame (29)
- # reitit (4)
- # rum (3)
- # shadow-cljs (119)
- # spacemacs (31)
- # xtdb (14)
Can Crux model one-to-many relationships in the reverse direction as Datomic can? For example, if a parent can have many children, how would a child find its parent?
hi @US05F3A2E ๐ yes - what do your documents look like? i.e. is it the child that's responsible for keeping a reference to the parent, or a parent to its children? (if you haven't already chosen, I'd probably go with the child keeping a reference to its parent)
Actually, I was thinking more in terms of many to many relationships. For example, if A points to x and y, and B points to y and z, how does y determine what points to it?
in that case, 'y' could be modelled as a document in its own right (useful if you want to store further details about y), or it could be an element in a vector stored in both A and B
when you have a vector as a value in a Crux document, we index each element separately - e.g.
(crux/submit-tx node [[:crux.tx/put {:crux.db/id :parent-doc-1
:myapp/children [:child-1 :child-2]}]
[:crux.tx/put {:crux.db/id :parent-doc-2
:myapp/children [:child-2 :child-3]}]])
(crux/q (crux/db node) '{:find [parent]
:where [[parent :myapp/children :child-2]]})
returns #{[:parent-doc-1] [:parent-doc-2]}
That's pretty cool. The domain I'm working on has a lot of many to many relationships between many different types of entities. I'm thinking of using namespaced UUIDs for IDs to make it easier to see what types the relationships refer to, eg, [:entityA/uuid1 :entityB/uuid2 ...]. Does that cause any problem for indexing?
Is there a recommended way of implementing a unique constraint, say on a person's email address?
Hi @US05F3A2E there was a recent thread about this exact thing: https://clojurians.slack.com/archives/CG3AM2F7V/p1581442893076700?thread_ts=1581442893.076700&cid=CG3AM2F7V ...I'll update the FAQ tonight ๐
Thanks for that! In my case, the unique value will usually be a composite of two or more attributes, one of which is usually a string. As there's the option of changing that string, I guess I'd then have to create a new unique document corresponding to the new string, and then delete the original document?
Yep that sounds about right. Using a map as an ID might help you there too: https://github.com/juxt/crux/commit/dd03a3613f9a076116d87ca0500f2350302ecec8
Looking at cruxdockerhub
, there isnโt anything there: https://hub.docker.com/u/cruxdockerhub
hey @dotemacs, thanks ๐ those are getting built as we speak, expect them under https://github.com/juxt/crux/releases and https://hub.docker.com/u/juxt shortly