Hi all,
We have two “regions” in our application. One in which the user can edit one model, and one in which they edit the children of that model.
We have two transactions and all commits/rollbacks are meant to be independent (ie: clicking “Save” in the children editing area shouldn’t effect the parent and vice versa).
This is resulting in:
All records in a changed relationship must be in the same transaction. You tried to change the relationship between records when one is in <DS.Transaction:ember765> and the other is in <DS.Transaction:ember766>
I understand the error, but I really want to use manage both the individual child records and there association with the parent in one transaction and the parent itself in another.
Can anyone think of a workaround? The only one that comes to mind would be to introduce an intermediate model that just sits between the children and the parent to ensure that the two transactions are totally independent. That doesn’t sound ideal…
Thanks in advance!
Have you tried using embedded relationships instead of the standard ones?
I’m also wrestling with this problem at the moment, and I have a feeling that using embedded relationships may solve it. However, I haven’t had the ability to test my theory because FixtureAdapter doesn’t support embedded relationships, and I don’t have a back-end yet (in fact, I won’t have one for a few months).
Knowing whether or not this theory is true would be a great help toward figuring out a solution or work-around.
I haven’t tried embedded relationships. We ended up forking ember-data, removing the assertions that were tripping and changing the way that associations are reloaded after a transaction commit. Hopefully ember-data will eventually get into a state where we can move back from our branch.
Here it is if you are curious: https://github.com/PrecisionNutrition/data
The specs fail for the case where you take an existing model and change it’s association (ie: if a “Dog” belongs to a “Person” and you change it so it belongs to another person and commit, that’s not handled in our hacked branch because we don’t need it…)
Bummer. We need support for changing existing models’ association. Thanks for the update anyhow.
Currently, I’m shifting related models to a common transaction only when a relationship changes (and moving them back afterward). That way the unexpected commit only happens when absolutely necessary. If it comes down to it later, I’ll investigate your initial idea of maintaining a relationship model, but I may not need to try that.
Peter Wagenet asked that we resurrect this thread for further discussion. At this point, I don’t have anything to add. This continues to be a requirement for us, and as such we’re working off our fork of ember-data.