This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-04
Channels
- # announcements (13)
- # babashka (19)
- # beginners (74)
- # boot (1)
- # calva (5)
- # clj-kondo (22)
- # clojure (46)
- # clojure-android (3)
- # clojure-dev (4)
- # clojure-uk (69)
- # clojurescript (19)
- # community-development (17)
- # cursive (27)
- # datomic (9)
- # emacs (13)
- # graalvm (2)
- # instaparse (4)
- # luminus (1)
- # off-topic (21)
- # reagent (6)
- # remote-jobs (1)
- # ring-swagger (4)
- # test-check (49)
- # vrac (1)
Or more generally are there good resources with example how to model more complex problems in datomic?
If you mean attribute which may be a string or keyword or long or something else, then string field with EDN content may work, but such approach may also indicate bad architecture decision 🙈 I used that in real-world project to abstract system configuration:
[{:db/ident :setting/name
:db/valueType :db.type/keyword
:db/unique :db.unique/identity
:db/cardinality :db.cardinality/one}
{:db/ident :setting/value
:db/valueType :db.type/string
:db/cardinality :db.cardinality/one}]
if you talk about attribute which is reference to another entity then there's nothing to model, as references are not typed
For polymorphic attributes I like the pattern of having an attribute whose value is the attribute where the value may be found, liked a tagged union
For “polymorphic” refs you can either do the same or just use one attr and tag the referent instead
Entities are just bags of assertions and have no type, so just “type” them as far as is useful.
For polymorphic attributes I like the pattern of having an attribute whose value is the attribute where the value may be found, liked a tagged union