Fork me on GitHub
#datomic
<
2017-02-13
>
uwo17:02:25

I know this is kinda silly, but is there a short cut to update a value on a nested ref? e.g.

@(d/transact
     conn
     [{:root-entity/_ref-attr <eid-on-hand>
       :nested-ref/value-attr “updated-value"}])

uwo17:02:04

like that, but obviously that clobbers the entire ref. I’m looking for more of an assoc-in

uwo17:02:00

(sorry, edited: was missing reverse reference)

pesterhazy18:02:11

Reverse refs don't work in transactions afaik

uwo18:02:32

they work fine 🙂

uwo18:02:00

but here’s another example for clarity. Again this doesn’t do what I’m looking to do, because it clobbers the entire ref instead of updating a value. And it’s a silly request because I know I can just use the root entity to query the entity id of the nested value and then use that to transact:

@(d/transact conn
  {:db/id <the-db-id-on-hand>
   :nested/ref {:ref/attr <new-value>}})

favila18:02:01

@uwo you need the id of the nested ref. Refs have identity semantics, not value semantics

uwo18:02:52

right, I know that if I already have the eid or a :db.unique/identity attribute I can use that. was just wondering if there was a way to navigate from parent without first looking up

favila18:02:32

There is no way to do what you want using just transaction maps. You could write a tx function that did what you want, but it would have to work by reading

uwo18:02:04

thanks! exactly what I wanted to know

favila18:02:22

thought experiment: tx maps work by expanding to the equiv db/add. How would you expand your assoc-in to a db/add without reading the nested id?

favila18:02:09

tx-maps have no more or less power than db/add and db/retract, it's purely syntax

uwo18:02:32

heh. I don’t know, but I could imagine expanding a reverse reference with the parent id in the same way that lookup refs are expanded

uwo18:02:22

errr… guess I should say lookup refs are ‘resolved’ not ‘expanded'

favila18:02:41

you also have to explicitly include them

favila18:02:14

but like I said, you could write a tx function that does what you want

favila18:02:29

an assoc-in, essentially. Reusing existing refs

uwo18:02:43

yeah, that makes sense. just do the read inside the tx fn

favila18:02:52

cardinality-many attrs would break the model

uwo18:02:12

thanks for your time!

pesterhazy18:02:29

is using reverse refs in txs a new feature?

favila18:02:47

In fact, it was the old default way of installing attrs and partitions

favila18:02:07

{... :db.install/_attribute :db.part/db} remember that?

favila18:02:03

reverse refs are no challenge, the :db/id of the map just gets put in the value slot of the :db/add instead of the entity slot

pesterhazy18:02:53

I always wondered why (as I though) it wasn't working because I figured the implementation would be trivial

pesterhazy18:02:11

now I know why - it did work all along 🙂

curtosis19:02:55

is anyone integrating e.g. conformity with component to manage schemas?

curtosis20:02:05

the idea I’m looking at is allowing certain components to depend on certain schema bits being loaded. I don’t think the component model is right for transacting the schema(s), but maybe something along the lines of a component providing the conformity ids that other components can then validate and decide what to do (rather than fail in a query).

curtosis20:02:16

is that crazy? being done? being done better differently?