This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-15
Channels
- # announcements (11)
- # beginners (66)
- # boot (6)
- # clara (25)
- # cljdoc (4)
- # cljs-dev (22)
- # clojure (261)
- # clojure-dev (1)
- # clojure-europe (2)
- # clojure-italy (15)
- # clojure-losangeles (1)
- # clojure-nl (19)
- # clojure-spec (62)
- # clojure-uk (50)
- # clojurescript (12)
- # community-development (6)
- # cursive (60)
- # datomic (21)
- # emacs (2)
- # figwheel (2)
- # figwheel-main (3)
- # fulcro (2)
- # graphql (11)
- # hyperfiddle (11)
- # javascript (1)
- # jobs (6)
- # juxt (1)
- # kaocha (5)
- # keechma (2)
- # off-topic (4)
- # onyx (10)
- # pathom (7)
- # re-frame (15)
- # reagent (8)
- # remote-jobs (2)
- # ring-swagger (14)
- # shadow-cljs (35)
- # sql (22)
- # testing (9)
- # tools-deps (62)
- # vim (12)
dsl seems to parse a thing :exists
as an operator, but it's not documented. This sounds like a missing feature we've wanted... is it true?
Good catch on the missing docs. There was some discussion on the list when it was implemented, see https://github.com/cerner/clara-rules/issues/130 for details.
@claudius.nicolae We are going to start heavily using clara-eav, and we have three big pieces of functionality to contribute back.
@eraserhd Curious what you contributed and if there’s support for multiple cardinality in clara-eav.
This doesn’t some how allow you to have: [42 :attr “a”] [42 :attr “b”] Because you can’t insert both of those correct? I’m not understanding how the multiple cardinality could work.
So then I’m not understanding what this does:
Many-valued Attributes
The shape of the pull result differs for many-valued attributes. clara-eql
assumes these attributes have a fact`(->EAV attr-name :db/cardinality :db.cardinality/many)`
I guess the eids actually would have to differ for this to work?
https://github.com/eraserhd/clara-eql/blob/develop/test/net/eraserhead/clara_eql/pull_test.clj
Is there a downside to that? This actually solves some data representation issues I was having.
Downside: inserted eavs won't be registered in the store's eav-index, and upsert won't retract them in subsequent calls with replacement values
limiting, in the sense that upsert won't retract them in subsequent calls with replacement values
I see, i think for my use case that’s typically OK as my data will be for the most part immutable.
I can limit upserts to where i need to have some “control flow” in the rules. This is really good.