Fork me on GitHub
#asami
<
2021-03-10
>
quoll00:03:00

Asami 2.0.0 alpha2 is now up.

🚀 5
👍 1
1
quoll00:03:27

This fixes a few things from Alpha 1, including a new serializable datatype for entity nodes that doesn’t use keywords

quoll00:03:57

Again, I’d love any feedback people have. Thank you!

quoll02:03:06

I’d like to comment that the reason it’s called an “alpha” is because I’m following the mantra “release early, release often”.

quoll02:03:34

So there will be things to fix! But any and all feedback will be helpful. Thank you

Andrea15:03:24

hello asamists 👋:skin-tone-2:, I’m somewhat confused by the semantic of retractions in Asami:

(def id
  (let [{:keys [tempids db-after]}
        @(d/transact conn
           [{:db/id -1
             :person/name "MsX"
             :person/address "10999"}])
        id (get tempids -1)]
    (println (d/entity db-after id))
    id))

(let [{:keys [db-after]}
      @(d/transact conn
         [[:db/retract id :person/address "10999"]])]
  (println (d/entity db-after id))) 
I’m seeing :person/address in the second call to entity but I wouldn’t expect that. Maybe I’m using wrong transaction data for the retraction? Tested this code with Asami 2.0.0-alpha2 (here’s a notebook to reproduce https://nextjournal.com/a/PDfq1fshbQsrL4dv6GDn6y/edit?token=X6uXajPPMadokXn62oh5Se)

quoll17:03:10

That confuses me too. I have a few things happening today look into this as soon as I can

quoll17:03:26

@U9EQP1K0X OK… it’s a bug. I’ve fixed it and am just writing a test for it now. Somewhat embarrassingly, no one I work with retracts statements this way, and I didn’t have full test coverage, so it was overlooked. Thank you very much!

🙂 1
quoll18:03:49

It’s up on github. I’ll make an Alpha 3 when I get back later today

Andrea19:03:13

oh, thank you so much! I’ll check that tomorrow.

Andrea19:03:03

I have more examples of retracting by db/idents which were not working as expected, will check those against alpha3...

quoll20:03:46

I’m not sure what “retracting by db/idents” might mean. “Retractions” are a statement describing an entity-attribute-value tuple to be removed, while a :db/ident is a way to identify an entity that is stored as multiple tuples. The only thing I can think of is what you provided in your example, where you used :db/ident to identify the node that represents the entity, and then using that in subsequent :db/retract statements.

Andrea09:03:58

> and then using that in subsequent `:db/retract` statements. yes exactly. I wonder if in the prior example giving a :db/ident say “id” instead of the tempid -1, then a retraction statement like [:db/retract "id" :person/address "10999"] would have worked. I tend to think about db/idents as https://docs.datomic.com/on-prem/schema/identity.html#lookup-refs but maybe I should not. Do Asami tx data in the vector form only support actual db/ids? (in other words node-1 mentioned in the wiki https://github.com/threatgrid/asami/wiki/Transactions#tx-data has to be a db/id)

quoll12:03:20

When I found the bug I did notice that it does not support this. I thought that maybe it should, but then realized that this sort of statement means that you are explicitly trying to remove statements during the same transaction that you’re trying to add them. This doesn’t make sense (in Datomic it causes an exception). It’s also difficult, because transactions are performed by performing deletions, followed by assertions. To make it work, these deletions would have to occur after the assertions that autogenerate that ID. Otherwise they’d delete a non-existing statement (a no-op) before inserting it, meaning that the statement would still be created.

quoll12:03:56

I could make it work, but I see no reason why it should. Unless there’s a use-case I’m not seeing?

mkvlr18:03:41

I think @U9EQP1K0X is talking about "id" as a :db/ident , not a temp id

mkvlr18:03:12

is it possible to perform a retraction using an :db/ident?

mkvlr18:03:40

asami does not support datomic style lookup refs, e.g. [:db/ident "id"] correct?

Andrea18:03:21

no, sorry for the confusion, it’s me not understanding well enough the :db/ident construct: I thought, since they can be used to lookup an entity which was asserted at any time via (asami.core/entity db my-ident) I thought that values of :db/ident could be used in vector statements for retractions in tx-data in 2nd position: eg [:db/retract my-ident attr val]

quoll18:03:08

Asami doesn’t have that lookup style… no. I made a ticket for it (and it won’t be hard), but it hasn’t been a priority.

mkvlr18:03:34

ok, so if you want to retract an attribute using a :db/ident you need to do a query for its :db/id first, correct?

👍 1
Andrea18:03:51

okay, we’re currently resolving :db/idents -> :db/id in retraction statements before transactions and it works well enough for the moment, I think

Andrea18:03:01

yes @U5H74UNSF doing that currently

quoll18:03:08

idents are used for identifying entities, and we (as in… my team) only really wants to delete things from entities when updating a property (meaning, delete the existing statement, and insert a new one), then we’ve used the entity update annotation for that

quoll18:03:28

Internally, all the entity code does those lookups for you. Which is to say that there’s no big deal moving it to other places as well.

mkvlr18:03:53

understood, supporting [:db/retract [:db/ident my-ident] attr val] would be useful for us, but of course also easy for us to do it before we submit the tx

quoll18:03:30

So if I have the entity:

{:db/ident "Mary"
 :name "Mary Smith"
 :age 22}
Then we can update by saying:
{:db/ident "Mary"
 :age' 23}
That does the lookup, retracts the [id :age 22] and assert [id :age 23]

quoll18:03:37

Sorry… I have to leave for an hour

mkvlr18:03:33

yes, so given that entity with a :db/id :

{:db/id 123
 :db/ident "Mary"
 :name "Mary Smith"
 :age 22}
you can update like you’ve written but if I want to retract the :age it’s only possible (without a query) using [:db/retract 123 :age 22] and it might be nice to also support [:db/retract [:db/ident "Mary"] :age 22] like in datomic

mkvlr18:03:13

also happy to look at that (probably tomorrow) if you’d accept a PR for this

👍 1
quoll20:03:28

If so, then it would go in src/asami/entities.cljc:133 and would probably do something like what line 60 does in that file

quoll20:03:52

(let [node-ref (if id
                             (and (seq (gr/resolve-triple graph id '?a '?v)) id)
                             (ffirst (gr/resolve-triple graph '?r :db/ident ident)))
This goes straight to the graph (skipping the query API with the associated costs), and checks if the thing being looked for is valid as an entity node (i.e. it appears in entity-attribute-value tuples in the entity position), and if that doesn’t work out, then it checks to see if the value appears in the value position for a statement where the property is :db/ident.

quoll20:03:35

the resolve-triple function returns a seq of bindings values. A bindings values is a vector containing position dependent bindings for the requested variables. So the first one will return a seq of vectors that have a count of 2 (representing values for the ?a and ?v), and the second will return a seq containing (hopefully) 1 vector, and that vector will have a count of 1.

quoll20:03:33

The (if id … part means that if a :db/id is provided, then that is considered canonical, and ignore the :db/ident

quoll20:03:26

These notes are in case you want to go ahead and do it. Otherwise, they’re a prompt for me to get it done 😉

🙏 1
quoll20:03:19

(oh… when I said line 133, that was for the deletions. Assertions will need to be treated the same way)

mkvlr13:03:41

thanks for those pointers, I’ll open a PR shortly

quoll14:03:14

Thank you @U5H74UNSF. I’ve responded to this

👀 1
quoll18:03:04

I also updated Zuko (which does the deconstruction of entities into triples) to include the lookup refs

quoll18:03:23

It’s in main, and will come out in the next alpha

quoll18:03:34

thank you again

mkvlr19:03:45

thank you!

quoll20:03:27

OK… this problem is addressed in 1.2.16 and 2.0.0-alpha3

🙏 3
1