Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2022-09-29

Channels

#datomic
<
2022-09-29
>
Leaf Garland02:09:10

I'd like to know if there are any guarantees around the ordering of multiple values for a binding in a query. For example in this query there could be 1 or 2 values for ?value and I am assuming that the order of those values matches the order of the rules in the or clause - so that the value of :some/attr1 will always be returned when present, falling back to the value of :some/attr2 when not. 

(d/q '[:find ?value .
       :in $ ?attr
       :where
       [?attr-id :db/ident ?attr]
       (or
         [?attr-id :some/attr1 ?value]
         [?attr-id :some/attr2 ?value])]
    db :test/attr)

favila02:09:10

No, they are run simultaneously, (at least in effect, if not always actually)

Leaf Garland02:09:48

Thanks! My initial tests were working the way I hoped but eventually I found some attributes where the order was different.

Leaf Garland02:09:20

Out of curiosity are there any Datomic docs or datalog articles I can read to understand that?

favila02:09:04

Datalog operates on sets, so there are no order guarantees about anything

👍 1
favila02:09:06

It’s so foundational an idea that I’m not sure it’s written down. But if it is I would expect it in the query tutorial or reference

Leaf Garland03:09:06

Just for future reference, I think this is what I was looking for. 

(d/q '[:find ?value .
       :in $ ?attr
       :where
       [?attr-id :db/ident ?attr]
       (or
         (and [?attr-id :some/attr1 ?value]
              (not [?attr-id :some/attr2]))
         [?attr-id :some/attr2 ?value])]
    db :test/attr)

jackmoch19:09:26

Hey there, does anyone know if there was any response or resolution to this https://forum.datomic.com/t/troubles-with-upsert-on-composite-tuples/1355? My team is running into issues when using composite tuples with a ref as an attribute: 

(def example-schema
  [{:db/ident       :my-first-string-attribute
    :db/valueType   :db.type/string
    :db/cardinality :db.cardinality/one}
   {:db/ident       :my-second-string-attribute
    :db/valueType   :db.type/string
    :db/cardinality :db.cardinality/one}
   {:db/ident       :my-ref-attribute
    :db/valueType   :db.type/ref
    :db/cardinality :db.cardinality/one}
   {:db/ident       :my-keyword-attribute
    :db/valueType   :db.type/keyword
    :db/cardinality :db.cardinality/one}
   {:db/ident       :composite-tuple/my-string-attribute+my-ref-attribute
    :db/valueType   :db.type/tuple
    :db/tupleAttrs  [:my-first-string-attribute :my-ref-attribute]
    :db/cardinality :db.cardinality/one
    :db/unique      :db.unique/identity}
   {:db/ident       :composite-tuple/my-string-attribute+my-keyword-attribute
    :db/valueType   :db.type/tuple
    :db/tupleAttrs  [:my-second-string-attribute :my-keyword-attribute]
    :db/cardinality :db.cardinality/one
    :db/unique      :db.unique/identity}
   {:db/ident :a-ref}])

(def example-docs
  [{:my-first-string-attribute "A String"
    :my-ref-attribute          :a-ref}
   {:my-second-string-attribute "Another String"
    :my-keyword-attribute       :a-keyword}])

(def db-uri "datomic:")
(d/create-database db-uri)
(def conn (d/connect db-uri))
(d/transact conn example-schema)
(d/transact conn example-docs)

(d/entity (d/db conn)
          [:composite-tuple/my-string-attribute+my-ref-attribute ["A String" :a-ref]])
;=> nil

(d/entity (d/db conn)
          [:composite-tuple/my-string-attribute+my-keyword-attribute ["Another String" :a-keyword]])
;=> #:db{:id 17592186045432}

dazld11:10:43

just in case you hadn’t tried it: 

(d/entity (d/db conn)
          [:composite-tuple/my-string-attribute+my-ref-attribute ["A String" (:db/id (d/entity (d/db conn) :a-ref))]])
=> #:db{:id 17592186045419}
when looking up the entity by a tuple id, it seems that datomic doesn’t try to turn values inside the tuple into an entity via lookup, even if we’ve described that position in the tuple as being a ref. That seems like a relatively easy bug to fix to me.

dazld11:10:02

I have no idea what the lookup code actually looks like, of course, but if the identity is a tuple, then walking the data provided as a value for that identity should be straightforward.

Casey18:10:38

@jackmoch Did you find a solution for this? Hitting the same problem with composite tuples + ref attrs here. Also it seems one can't update an entity by only asserting the individual ref attrs, one must also assert the composite attr which contradicts the documentation.

jackmoch11:10:25

@U70QFSCG2 We ended up pushing the entity resolution as far down the stack as possible so the callers can pass around the tuple and it gets resolved just before the query, pull, etc is executed It definitely didn’t feel like the cleanest resolution so we also got rid of one usage pattern completely and are mainly using them for enforcing uniqueness on composite attrs I did hear back from the Datomic team and they’re aware and considering options but I’m not sure what that looks like in practice. I also did see a mention of lookup refs in the newest datomic changelog but I haven’t tried the new version yet to see if it impacts any of this behavior

onetom18:10:33

We also wish for smarter lookup refs, to simplify composite key situations. I still have the feeling, that I might be doing something wrong and that's why I'm in need of such a feature, but not sure how to simplify our data model... 😕

Casey19:10:32

Fwiw we're moving from composite keys, which would otherwise naturally arise in the data model, to synthetic keys (uuids) and manual checks in the pre-transact code to enforce the unique composite relationship. It's not as pretty or elegant but results in more straightforward and readable code.

magnars19:10:22

We had to resort to {:my-entity/composite-id (pr-str [id-1 id-2])} to get upsert, instead of using tuples.

onetom11:10:36

i also ended up writing some transactor functions to achieve upsert behaviour, when i was using composite keys. really feels like im doing something wrong... we are dealing with 3rd-party data, which is partitioned by external users and tenants/orgs too, so most of our entities have composite key with 1. a ref attribute to the 3rd-party org entity 2. a 3rd-party ID, which is unique within the 3rd-party org, but not across orgs necessarily i would think, that this must be a pretty common scenario, so im a bit surprised how clunky is it at the end to work with it. would be pretty nice though, if the lookup refs would be more nestable...

magnars19:09:50

We had the same issue with refs in tuples, and had to find some other solution for it. Would be interested to hear if there is any progress on this.

➕ 2
Casey18:10:38
replied to a thread:Hey there, does anyone know if there was any response or resolution to this https://forum.datomic.com/t/troubles-with-upsert-on-composite-tuples/1355? My team is running into issues when using composite tuples with a ref as an attribute: (def example-schema [{:db/ident :my-first-string-attribute :db/valueType :db.type/string :db/cardinality :db.cardinality/one} {:db/ident :my-second-string-attribute :db/valueType :db.type/string :db/cardinality :db.cardinality/one} {:db/ident :my-ref-attribute :db/valueType :db.type/ref :db/cardinality :db.cardinality/one} {:db/ident :my-keyword-attribute :db/valueType :db.type/keyword :db/cardinality :db.cardinality/one} {:db/ident :composite-tuple/my-string-attribute+my-ref-attribute :db/valueType :db.type/tuple :db/tupleAttrs [:my-first-string-attribute :my-ref-attribute] :db/cardinality :db.cardinality/one :db/unique :db.unique/identity} {:db/ident :composite-tuple/my-string-attribute+my-keyword-attribute :db/valueType :db.type/tuple :db/tupleAttrs [:my-second-string-attribute :my-keyword-attribute] :db/cardinality :db.cardinality/one :db/unique :db.unique/identity} {:db/ident :a-ref}]) (def example-docs [{:my-first-string-attribute "A String" :my-ref-attribute :a-ref} {:my-second-string-attribute "Another String" :my-keyword-attribute :a-keyword}]) (def db-uri "datomic:<mem://example>") (d/create-database db-uri) (def conn (d/connect db-uri)) (d/transact conn example-schema) (d/transact conn example-docs) (d/entity (d/db conn) [:composite-tuple/my-string-attribute+my-ref-attribute ["A String" :a-ref]]) ;=&gt; nil (d/entity (d/db conn) [:composite-tuple/my-string-attribute+my-keyword-attribute ["Another String" :a-keyword]]) ;=&gt; #:db{:id 17592186045432}

@jackmoch Did you find a solution for this? Hitting the same problem with composite tuples + ref attrs here. Also it seems one can't update an entity by only asserting the individual ref attrs, one must also assert the composite attr which contradicts the documentation.