Use new Firebase mult-location writes for Emberfire relationships

[gabrielgrant]

The extra manual tracking that Emberfire requires around relationships is a real footgun. Now that multi-location atomic writes are supported it seems Emberfire should make use of those to just automatically update both sides of a relationship following some variation of the fan-out pattern.

[tstirrat]

Similar to #304

I think the solution is to just write the model payload + relationships array in one step.

[gabrielgrant]

Yes, I was specifically talking about writing both sides of the relationship without requiring a save() call on each model. It's pretty explicit in the relevant Ember docs that this isn't supposed to be required, and I read somewhere recently that this was one of the reasons Emberfire was ruled out for a new intro-to-ember tutorial. (I can't seem to find that discussion at the moment, I'll update with the link if I come across it again)

[tstirrat]

Please do, if you can find the link.

In regards to saving on both sides. As far as I know, the standard REST adapters do no do this automatically.

What is often happening is that the relationship is stored on the server in only one direction and a single save is all that is needed. This same functionality also works in EmberFire -- it auto reconciles the relationships locally when only one side is defined. However, if you define it on both sides you need to save it on both sides.

[gabrielgrant]

I believe you're right that the standard REST adapters don't automatically, explicitly save both sides, but as I understand it, the difference is that they assume that if the relationship gets saved on one side, then it will automatically appear when (re)fetching the other side (as would generally be the case with a standard relational backend). Firebase isn't doing this bi-directional linking for us, so to simulate this behavior requires the client to write to both locations.

Hope that makes (some) sense? :)

Also, in this particular case, it probably does make sense to save the foreign relationship without saving the whole foreign model (though I agree with you in #304 that generally the save should all happen together)

[tstirrat]

I agree this could help with relationships but it is not something I'm actively working on. PRs welcome. As I stated in #147, the edge cases and interplay with Ember Data's internal relationship reconciliation might get tricky.

[AndersDJohnson]

+1

[alexparker]

+1, any update here?

[jamesdaniels]

Closing in favor of #366