I put this in SO: https://stackoverflow.com/questions/45046582/create-entity-that-refers-to-an-existing-entity

If anyone can help or point me to where the documentation is. Thanks..

@cjmurphy I think you need to do first twice in read-account

d/q returns a sequence of tuples. You want the first element of the first tuple I think

@pesterhazy Interesting - so it really is just supposed to be just a number?? I've been thinking of using (d/entity db bank-acct-id) - to really put an entity there. I can't test either approach (`ffirst` or d/entity) right now as there seem to be other problems I need to sort out. Thanks and I'll be back..

an entity id is just a long, yes

And d/entity will work as well because of upserting, but is kind of pointless??

you can also find a unique identifier for your entity and use that in a lookup ref like so: [:my.entity/name "CJ Murphy"]

@cjmurphy I agree with Peter, or you can use .... :find ?a . (notice the trailing dot)

That'll return a single value

Make it a scalar

*Paulus 🙂

Ooopsie, sorry Paulus. 🙂

not sure what you mean about d/entity

That's a function you pass an eid and it returns the data.

I went for that idea when I thought just putting a number there was wrong. But you guys have corrected me now. thanks.

my rule of thumb is not to expose entity ids to the outside

but it's fine to use them within your code

So put a db/id there in preference to an eid?

Definitely within the code.

:db/id is the entity id

Oh right. So when I pull on [:db/id] I'm doing something senseless.

Does Datomic database functions support multiple arity? (fn [arg1] [arg1 arg2])

Hi! We are doing PoC of global data registry, where we trying to specify the shape of our data from various sources using clojure.spec. We considering to use Datomic as spec storage. Is it a good idea to store a clojure.spec expressions as Strings in Datomic? Spec is used in application level, where we do ETL, validation, transformatio, sample generation.

Is it possible to change the owner of an entity referenced via an isComponent attribute in a single transaction?

Ah, I should specify that the original owner is deleted in that same transaction.

Example: in a tree, replace a node with one of its children, deleting the replaced node and any of its children that are not the one that replaced it.

@tomc [:db.fn/retractEntity the-parent] will retract the is-component children. So you can do it only if you don't use retractEntity

So if I explicitly retract all attributes of the parent it'll have the same effect, except I'll be able to move the child to another parent?

You can always move the child; the question is whether there will be any assertions left on the child.

Yes you can do what you propose. But it sounds like maybe your attribute should not be is-component?

In my case I think isComponent is the right choice, and using explicit attr retractions on the parent will probably solve my problem.

is-component attrs have a (not-enforced) invariant that the :v of every datom with that attribute is not the :v of any other datom

IOW, the "child" entity (value of the is-component attr) is not reachable except from a single parent and that one attribute.

Understood, but if I make that change in a single transaction, that invariant is not violated, correct? This seems like something I could write a transactor function to handle...

@tomc true, it is not. it's just strange for the lifetime of the child to outlive the parent. If you keep the invariant you will be fine though.

Ok, thank you for the help.