Implement dirty tracking and rollback of belongsTo relationships.

[arenoir]

Issues #3696, #3045

[fivetanley]

This looks good to me. Would prefer for @wecc or @igorT to review though. Great work!

[svox1]

Any news on this? Would be great if releationships can rollback again.

[ptgamr]

+1

[fivetanley]

@arenoir sorry for the delay, I'll make sure it gets discussed at this week's meeting.

[fivetanley]

@igorT has agreed to write an RFC for relationship tracking.

[eshtadc]

+1 on this issue

[arenoir]

@fivetanley any word on this? fyi I rebased with master.

[nicksteffens]

👍

[Keeo]

Please 👍

[thedrew12]

+1

[fivetanley]

@arenoir I pinged @igorT about this yesterday. He said he should be able to write an RFC for an alternative approach. Hopefully he can fill in here more when he has a chance...

[fivetanley]

I apologize for the long delays

[arenoir]

No worries @fivetanley, I look forward to the RFC. Perhaps I am beating a dead horse but @igorT would you take a look at the conversation I started regarding the difference between hasOne and belongsTo. I think it relates to the RFC you may be putting together.

[aaronbhansen]

👍 this would be useful

[fivetanley]

We all agree it would be useful. ;)

[nanuxbe]

👍 I've been implementing an re-implementing this for ages every time ember-data changes. It would definitely be useful.

[bmac]

I'm going to close this pr. @igorT is working on an RFC to describe what needs to happen to for Ember Data to support relationship rollback for both hasMany and belongsTo.

[epyx25]

I've been implementing an re-implementing this for ages every time ember-data changes.

@nanuxbe could you share to us in a gist?

[xomaczar]

Any news on the before mentioned RFC?

[abhilashlr]

👍 Any news on the RFC? Would love to see this rollback for belongsTo resolved.

[erkie]

How can we help get this issue fixed? What's the blocker?

[malatin3]

This is a huge pain point with ember data for us. Would love to see this merged.

[XaserAcheron]

At risk of being "that guy": I'm struggling through this at present, and it feels a lot like I drove a car into a parking space only to find out the next day that the car can't reverse.

I get that this is a hard feature to add, but I'm un-thrilled about the radio silence as of late.

[erkie]

One solution for certain cases is to use ember-data-model-fragments.

I found that to implement arrays of plain objects or primitive types I was modeling them as ember-data relationships, when I didn't really want or need the overhead of the ember-data object.

[broerse]

Should this be called isDirty ? Perhaps more logical:

hasDirtyFields: Ember.computed.or('hasDirtyAttributes', 'hasDirtyRelationships')

[workmanw]

This was marked "Needs Team Discussion" nearly two years ago. Was there a discussion on this? Is there anything that can be shared from the core team about this? As a long time ember user, it's just down right frustrating to see PRs with a lot of support sit without any feedback.

[Ramblurr]

I just watched a coworker spend over an hour working to debug an issue that turned out to be caused by inadvertently checking hasDirtyAttributes when the user changed a belongsTo value.

This exactly describes my afternoon. Incredibly frustrating!

[runspired]

@workmanw the short answer is that there have been many tried and failed attempts at resolving this by the core team. Discussions, spiked implementations, concepts. Ultimately it comes down to this being one of the hardest concepts to solve generally because there is simply so much variation in API design (even tying to json-api spec doesn't solve this issue for the most part).

This was one of the first things I looked to "fix" when I began working on ember-data two years ago. It took me a few weeks to understand the full scope of the issue and quite obviously nothing ever came of that. It's a problem that seems simple at first and quickly becomes the most complex issue any ORM can possibly face.

The above said, over the past few years we've identified a few areas that if-improved would improve our ability to potentially, maybe, eventually rollback relationships.

• dirty both sides of the relationship
• determine new dirty-state when new relationship data comes in (requires changing our current diff, which needs to change anyway to resolve pushPayload does not change hasMany relationship when going to empty state #4804 )
• improve documentation of the contract between adapter and store, and educate on available patterns

There's also a few ideas that still have merits but don't solve the problem the way they first appear to:

• single source of truth for relationships

And some ideas that just won't work due to API complexity

• in-flight relationship data

You'll maybe note that in-flight is in the "just wont work" category here. Ultimately this is the core reason why rollback has never successfully landed. It's also a much harder problem to solve for many relationships than it is for belongsTo, and the solution here does not address that, leaving many pitfalls and bugs for users to still encounter. In the general case, here's a simple fail scenario for 1:1 relationships to illustrate the difficulty of rollback during a save:

• A 1:1 B
• A sets B
• B saves (which in this API does save the new relationship)
• A rollback of B before B save completes
• B resolves with no new relationship info (APIs in the wild often will not)
• A:B linkage does not exist though it should

Ultimately, the store is incapable of storing in-flight state for relationships. However, adapters are well suited for this, and if we improve usage patterns in the request layer and improve our ability to correctly respond to changes in canonical state we will unlock the ability for users to implement relationship rollback locally as well.

Bear in mind, all of this discussion is only for the viewpoint that rollback and dirty tracking of relationships is for the linkage, not the state of the related records themselves. That's a very different concept, and not one that rollback should cover on the record level.

[runspired]

Closing this in favor of addons like ember-data-changetracker and use of a RecordData based approach. That said improved relationship primitives are in the works for RecordData authors to make use of, and would include tracked changes for easier rollback and diffing.