for some reason if i tried to add relationships on same entity for more than one time like first authors to work then work to edition, then the later one override the previous relationship. so expected result should be work having two relationships but found only one :(
2022-07-06 18713, 2022
Shubh
that is work to edition...
2022-07-06 18736, 2022
monkey
Can you point me to the code? Looks like the relationships array/map get overwritten
2022-07-06 18738, 2022
Shubh
might be issue with orm?
2022-07-06 18720, 2022
monkey
To figure out where it comes from, I would: 1. check the redux state before submitting (with Redux Devtools) 2. put a breakpoint in the server code submit route to check the content of the body that is sent 3. Put breakpoints in the part of the server code that creates the new relationshipSet for the revision
Hm. Can you check in the database if the master revision of the entity you're modifying has a relationship_set_id ?
2022-07-06 18704, 2022
monkey
If it does, then the ORM is returning something it shouldn't (or some other part of the code is broken)
2022-07-06 18717, 2022
Shubh
yep it does have
2022-07-06 18730, 2022
monkey
Also check in the DB if the relationship set has the relationship(s) you expect it to have
2022-07-06 18712, 2022
monkey
This is all happening in the uf-frontend branch I suppose? I can test locally
2022-07-06 18718, 2022
Shubh
here as you can see, work links with author properly but later revision(*85) modifies relationship on work with edition and removes the old relationship with author https://usercontent.irccloud-cdn.com/file/jkw2W6b…
2022-07-06 18758, 2022
Shubh
monkey: hmm, any branch which have POST route PR merged
2022-07-06 18723, 2022
monkey
So there's something I notice straight away: the revisions are not created in order
2022-07-06 18724, 2022
monkey
So I'm guessing at some point of the transaction the entity model doesn't have the updated relationship set id
2022-07-06 18711, 2022
Shubh
hmm but does revision order have any effect?, serial number of revision looks fine to me that is adding relationship on edition at last
2022-07-06 18710, 2022
monkey
It's more a hint that the issue is with the creation of the revisions rather than with the ORM I guess
2022-07-06 18720, 2022
Shubh
does seem like an issue with transaction, like we had previously when doing thing async
2022-07-06 18708, 2022
monkey
Look at this piece of code: I had to call .refresh on a relationship set that might have been modified by some other part of the transaction, precisely for the same reason: https://github.com/metabrainz/bookbrainz-site/blo…
2022-07-06 18711, 2022
monkey
You'll need to find where exactly you need to get a more up-to-date representation of the relationshipset before modifying it again. Since we are in a transaction, we don't necessarily have access to the updated rel-set, instead we still have info about the previous rel-set before it being modified.
2022-07-06 18736, 2022
monkey
What I mean by that is that in a transaction we can't assume that the operations we want to do are happening in order and the later operations can assume the previous ones have happened already. So we can't rely on a change having happened, even though the code reads pretty linearly.
2022-07-06 18721, 2022
monkey
However we can push the ORM to return up-to-date data for each model with the `.refresh({transacting…` incantation
2022-07-06 18700, 2022
monkey
Obviously it gets a bit more complex when you are creating/modifying more and more entities :)
2022-07-06 18758, 2022
monkey
Perhaps it would be as simple as calling .refresh(… in getNextRelationshipSets ?
my bad, but this should be null since at that time edition didn't have any relationship thus resulting in null
2022-07-06 18723, 2022
monkey
Ah, OK, that makes sense
2022-07-06 18714, 2022
monkey
But I guess that's the trick: it's null in the database, but might have been created in the transaction (i.e. not-commited-yet info which you can retrieve with refresh)
2022-07-06 18748, 2022
Shubh
not sure if refresh will work since entity will have relationshipSetId as null initially
2022-07-06 18749, 2022
monkey
But in revision 84 you add a relationship as part of the transactions, no?
Yes but it does return correct relationshipshipSetId for work ( that has relationship with author_
2022-07-06 18757, 2022
monkey
So #84 results in a new rel-set, and while adding rels in #85 we get the correct rel-set id, but not the relationships in it are replacing the existing ones instead of being added, is that it?
2022-07-06 18700, 2022
monkey
"but not the relationships in it are" -> "but the relationships in it are"
2022-07-06 18729, 2022
Shubh
Yep!
2022-07-06 18750, 2022
Shubh
thats why i suspected something might be related with orm
2022-07-06 18704, 2022
monkey
OK, we're narrowing it down. Looks like withRelated: 'relationships' does not fetch the updated rels.
