asami 2022-07-20 | Slack Archive

I don't know what is happening. I seem to be unable to retract an entity fully. I do

(d/transact conn [
 [:db/retract :a/node-78464 :id [:address/id #uuid "ffffffff-ffff-ffff-ffff-000000000001"]]
 [:db/retract :a/node-78464 :address/id #uuid "ffffffff-ffff-ffff-ffff-000000000001"]
 [:db/retract :a/node-78464 :a/entity true]
 [:db/retract :a/node-78464 :address/street "X St"]])

yet the transact's returned :tx-data only have 3, not 4 datoms, missing the first one with :id :

(#datom [:a/node-78464 :address/id #uuid "ffffffff-ffff-ffff-ffff-000000000001" 2 false]
 #datom [:a/node-78464 :a/entity true 2 false]
 #datom [:a/node-78464 :address/street "X St" 2 false])

How is this possible? What am I doing wrong? 🙏

quoll22:07:06

That looks like a bug. All that effort for searching for :id and creating an element may be creating the very entity it’s trying to remove 😕

👍 1

Jakub Holý (HolyJak)21:07:50

Should I create a bug report for this? But I see that https://github.com/quoll/asami still hasn't issues enabled (I believe you were blocked in doing so by somethign, what I do not recall)

quoll21:07:44

Oh… that may have been due to wanting to import prior issues. Whatever, I can do it manually.

quoll21:07:56

I turned them on. Thanks for letting me know

🙏 1

quoll22:07:38

I will need to work on it

quoll22:07:14

Also, I need a function for retracting entities. Basically, I need a function that finds all triples for an entity (`:a/owns` helps here)

🙏 1

Jakub Holý (HolyJak)22:07:46

I have a test that, with a simple change does or does not exhibit the problem ☝️ :

(deftest delete-ident
  @(d/transact *conn* {:tx-data [{:id [:test/id "existing-ident"]
                                  ;:test/id "existing-ident" ; <----- uncomment to break the test and show the issue
                                  }]})
  (let [eid (d/q '[:find ?e . :where [?e :id [:test/id "existing-ident"]]] (d/db *conn*))]
    (write/retract-entity *conn* [:test/id "existing-ident"])
    (is (= nil (d/entity (d/db *conn*) [:test/id "existing-ident"])) "The entity is no more")
    (is (= '() (d/q '[:find ?e ?a ?v :where [?e ?a ?v] :in $ ?e] (d/db *conn*) eid)))))

; where write/retract-entity is:
(defn retract-entity [conn id]
  (d/transact
    conn
    (d/q '[:find :db/retract ?e ?a ?v :where [?e ?a ?v] [?e :id ?id] :in $ ?id]
         (d/db conn) id)))

quoll22:07:31

That :tx-data looks wrong.

quoll22:07:35

You’ve defined an entity:

{:id [:test/id "existing-ident"]  ;; this is basically: `:id serialized-blob`
 :test/id "existing-ident"        ;; this is:           `:test/id "existing-ident"
}

That serialized blob happens to deserialize into the same key/value that the entity itself has, but it’s basically unrelated

Jakub Holý (HolyJak)06:07:59

Thank you. How is the fact that they are different important here? They still are attached to the same entity, no? And I should be able to retract both, no matter whether they are related or not? (FYI I use this form of ID b/c I cannot be sure that the ID value is globally unique while I know it is unique for the entity type, which is what ::address/id encodes)

quoll14:07:40

> How is the fact that they are different important here? Well, one is a 2 element vector, and the other is a key and value on a map. The vector could have any amount of information in it, but in this case it happens to be 2 elements, which happen to correspond to the key/value pair on the map that it’s a part of. I’m not sure why you might think they could be related in any way. > They still are attached to the same entity, no? OK, but If I have an object: {:age 5, :height 5} then both of the values in the object are the same. Your question implies that they should be treated as the same thing in some way. > And I should be able to retract both, no matter whether they are related or not? Yes. But as I said, I suspect there may be a bug where the code that searches for :id to ensure that an object is created is not filtering by :db/add and is also picking up on the :db/retract

Jakub Holý (HolyJak)21:07:06

It seems to me that we talk past each other 😢 You mentioned > Your question implies that they should be treated as the same thing in some way. I am not sure what you refer to but I am sorry for the confusion, I believe I did mean no such thing. Yes, in practice they are related, the key and value of the second property is included in the value of the :id property but I do not expect Asami to know or care about this. From the point of Asami these are two separate and independent properties and that is fine. (For context: Fulcro uses :<entity>/id <value> to identify uniquely individual data entities. For me that is not enough because I also need an easy way to refer to these entities in Asami, which is why I add :id to them (I could also use db/ident instead). However I cannot be usre that the <value> is globally unique while I know that the pair of <entity> <value> is, that's why I use the vector as the id.)

quoll21:07:41

Sorry for messing up

Jakub Holý (HolyJak)21:07:09

Sorry for being unclear 🙂

quoll21:07:11

But yes… vectors as IDs should work

👍 1

Jakub Holý (HolyJak)21:07:09

Actually, despite my expectation, it seems Asami actually sees a relation between the two properties in {:id [:test/id "existing-ident"],:test/id "existing-ident"} - if I change either the key or value of the second property then the problem of :id not retracted does not occur.

quoll21:07:54

I'm confused how this could be

quoll21:07:22

:test/id has no special meaning as a key, and the vector after :id gets serialized into the data pool as a blob, and the blob's internal id is the value that's stored in the triple

2022-07-20

Channels