In a same space I have to database A and B. A has a one-to-many to B and B has a one-to-one to A. When a trigger happens in an entity of A, I want to get the list of all entities of B related to it, filter some of them and delete the rest. I try log an entity of A from args.currentEntities
, but I don’t see the field B. But I can see field A when I log an entity of B. Why is that?
Do you mean that there are two relations?
Or do you mean a single relation, such that A can link to many Bs, but each B can only link to one A?
Assuming the latter, when you have a button/rule in the A database, then the linked B items will be available via [Step 1 A].[Bs]
(assuming the field in db A for linked Bs is called Bs
)
If you want to change which B entities are linked to A (to only be a subset of those currently linked) then you can use the update action, choose field Bs
to be updated, and use a formula, e.g.
[Step 1 A].[Bs].Filter(X = Y)
I create the relation in db B and in A the reference of B shown up, so I guess it’s a single relation.
I’m using rule and writing script. I don’t know where the formula locates. Can you give me a screenshot?
You shouldn’t need to use a script.
(the guide applies to buttons and rules equally)
Hmm, as I have already written a complicated script, I want to manage everything in one place. Plus that I can control the data better. Is there a way to make it a script?
If you’re insistent on using a script, then you will have to use args.currentEntities
to get the A entity, and then use getEntityById
to explicitly get its related Bs.
When you get an entity object, by default, only the primitive fields and any to-one relations are included in the fields returned. If you want to get the collection fields (to-many relations) you have to query specifically for them.
Does that mean that I need to store the IDs of the B entities locally in order to be able to query them?
Not sure what you mean by ‘storing IDs locally’.
In general, your script will need to get A (using args.currentEntities
) and then get the B IDs (using getEntityById
on the A entity) and then if you then want to filter the Bs in some way, you may need to query them further (using getEntitiesById
on the array of B IDs).
So I suppose you could call that ‘storing IDs’
Thanks. Somehow I mix up args.currentEntities
with fibery.getEntityById
Is there any reason behind this decision?
I suppose because there has to be a limit drawn somewhere as to what gets returned when you query an entity, to avoid the query taking too long