This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-05-09
Channels
- # announcements (3)
- # beginners (61)
- # biff (20)
- # cider (13)
- # clerk (6)
- # clojure (58)
- # clojure-brasil (5)
- # clojure-europe (30)
- # clojure-nl (1)
- # clojure-norway (10)
- # clojure-uk (5)
- # clr (25)
- # core-async (2)
- # cursive (19)
- # datahike (5)
- # datalevin (1)
- # docker (1)
- # emacs (3)
- # fulcro (4)
- # hoplon (3)
- # hyperfiddle (91)
- # java (2)
- # juxt (5)
- # london-clojurians (1)
- # lsp (38)
- # malli (12)
- # nrepl (9)
- # off-topic (7)
- # polylith (15)
- # portal (49)
- # rdf (2)
- # re-frame (43)
- # releases (2)
- # shadow-cljs (30)
- # spacemacs (15)
- # sql (36)
- # tools-build (20)
- # xtdb (3)
Morning
Salvēte!
måning!
anyone know of a clj/s lib (or something from outside of the clj/s ecosystem but usable from clj/s) which models persistent entities and relationships ? i'm looking for something which maintains a repository of metadata about schema, keys and relationships, ideally with some notion of schema evolution - but not tied to a particular store... (confluent schema registry is reasonably close, but quite tied to confluent platform)
i've half-implemented something similar a couple of times and it makes a great foundation for a storage layer, but if someone else has done a better job i would be all over it
You mean like a hibernate/ ORM?
not quite - i don't want any actual persistence - i just want modelling and ideally the sort of versioning help (strictures) that confluent schema gives you - e.g. preventing you modifying schema in a backwards incompatible way
so i suppose it's like part of hibernate - just the entity modelling part, without any of the actual persistence
e.g. this lib defines a simple model of collections ( https://github.com/yapsterapp/expo-collections/blob/trunk/src/yapster/collections/schema.cljs#L93 ), and uses it to create SQLite storage resources on mobile devices, and update those resources when collection models ( https://gist.github.com/mccraigmccraig/2a7c609048dc7d4d078f98937e9b528f ) change
but both hibernate and that last example are very tied to implementation... i think it's possible to do better
spec (or malli) is a good start... although less than i want - aside from backwards/forwards compatibility, other concepts i've found useful include keys and key-extractors ... that bag of concepts (schema, version-compatibility, keys, key-extractors) is just about enough to automatically manage storage resources, at least for document-oriented stores
the avro people have really thought hard about the compatibility thing : https://medium.com/codex/understanding-avro-compatibility-e2f9afa48dd1
https://github.com/pfeodrippe/recife/blob/master/test/recife/example/alloy/migration.clj useful?
woah I didn't know you could run alloy inside of clojure
well that is certainly interesting @U09LZR36F... will have to think on it... i hadn't come across alloy before
i'm currently looking at converting some subset of malli to avro schema... looks like there is some prior clojure art ( https://www.youtube.com/watch?v=cRc0a4HJ7aI , https://github.com/dvingo/malli-code-gen/blob/malli-avro/src/dev/ivan_play2.clj ), and it would let me use the kafka schema registries and schema-based serde stuff
pretty happy with the colours on these flowers https://photos.app.goo.gl/n2HPNR1uFa6sQVaSA