This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-08-06
Channels
- # babashka (101)
- # beginners (47)
- # biff (7)
- # calva (36)
- # clj-kondo (19)
- # clojure (11)
- # clojure-europe (1)
- # clojurescript (4)
- # conjure (4)
- # core-typed (3)
- # cursive (24)
- # emacs (22)
- # events (4)
- # gratitude (1)
- # introduce-yourself (1)
- # malli (27)
- # meander (5)
- # off-topic (101)
- # portal (5)
- # shadow-cljs (26)
- # tools-build (4)
- # tools-deps (3)
- # vim (8)
- # xtdb (13)
I’m thinking about using xtdb as a neo4j alternative for parts assemblies with subassemblies… I use labeled edges and the like with neo4j… does anyone know of an example of anyone approximating this in xtdb?
Hey @U0X9N9ZK5 I don't have an example handy, but you could use a map ID (or construct a concatenated string ID, etc.) for an entity that represents the edge, e.g. `{:xt/id {:from "foo" :att :bar :to "baz"} :label-att "label-val"}
@U899JBRPF I think this was one of my first questions to you, when I was moving off Neo4j in favour of Crux xtdb. 🙂 "Edges are just another document" really grew on me, the more I thought about it.
Is there a reason to use a map id over top-level :from
and :to
attrs, in your example? Or would you use both?
Storing the ID component values separately may also be useful should more complex querying over labels be needed (not just lookups)
@U01AVNG2XNF Did you manage to implement a graph in xtdb in the end?
My use case is for graphs, but I’m desperate to stay in xtdb because it’s so awesome (and all the other advantages).
I have been searching for examples online, but forgot to try queries with crux as opposed to xtdb.
the repo 404's, alas.
@U0X9N9ZK5 This is a long and hairy story, but my did end up building a digital library (or, perhaps more accurately, the beginnings of one) with XTDB. Whether one considers the underlying data model a "graph" is a question of semantics. In the end, I didn't choose to implement any entities which represent edges. (Yet.) I've found that for the kinds of graph traversals I'm interested in, arbitrary relationships are sufficient. I know the types/labels of my nodes, and at the scale I'm dealing with, that's proven more than enough. That said, I like the fact that I didn't need to build edges in everywhere — and that I didn't feel obligated to, since I can always add edge entities later to augment the node-based data model. Apologies if that's a bit of a cop-out, but the option to grow the "graph-iness" of my data model is actually really attractive to me. Starting with arbitrary joins, adding edge entities if necessary, and then adding rules later (should I find I need them).
@U01AVNG2XNF Thank you for this! It’s helpful. It sounds like it can be done, even if you haven’t done so quite yet, which is attractive. The idea of being able to use xtdb across the board is what’s appealing to me.
The main source of that Nextjournal link is https://github.com/xtdb/xtdb/blob/e2f51ed99fc2716faa8ad254c0b18166c937b134/docs/example/repl-walkthrough/graph-traversal.clj