Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Allow parent and child records to be saved in the same commit #440

wants to merge 2 commits into


None yet

pivotal-medici commented Oct 26, 2012

Currently (as of 4c47535) you can't create a new parent and child record in the same commit (see #437).

We're hoping to use this pull request as the start of a conversation about how best to fix this issue. We've added a failing integration test for the interaction between the store and REST adapter.

The current error is:

<DS.StateManager> could not respond to event didChangeData in state rootState.loaded.created.inFlight

This happens because the store, upon receiving a call to didSaveRecord, assumes the parent is in the loaded.saved state. It's not, however, because it still has a dirty factor for its has-many relationship.


elliterate commented Nov 1, 2012

In DS.RESTAdapter, we've implemented a delayed create and update for children of new parents.

In addition to integration tests, we've also added unit tests for DS.RESTAdapter#createRecord and DS.RESTAdapter#updateRecord that demonstrate just how the adapter is expected to behave.

To get around the "could not respond to event didChangeData" error, we cloned the existing didChangeData event onto the inFlight state. It didn't seem like that would be a problem, as that event wasn't triggering a state change—just materializing the new data.


pivotal-medici commented Nov 5, 2012

We removed the sinon.js depedency.


pivotal-medici commented Nov 15, 2012

We found and fixed another issue preventing some parent-child pairs from being saved in the same commit. If the response from the server includes updated data that needs to be sideloaded into one of the other in-flight objects, the state manager for that object will complain that it can't trigger 'loadedData' while in flight. See our second commit for a more thorough example of the problem.


pivotal-medici commented Dec 4, 2012

We added an adapter hook to determine whether dirty records should be preserved on materialization.

We also rebased against current master.


tomdale commented Dec 15, 2012

@wycats and I are in the middle of a huge refactor of the REST adapter to support embedded relationships. We will get this in as soon as that work is finished. Thank you for your patience!

go1dfish commented Jan 8, 2013

Any updates on this now that the embedded relationships refactor is merged?

@go1dfish go1dfish referenced this pull request in escalant3/ember-data-tastypie-adapter Jan 8, 2013


Add support for saving graphs of objects #10

I'm really interested in this feature. Any update?

Me too :)


ghempton commented Feb 8, 2013

This is a cool feature, however these semantics are a little too specific for a generic rest adapter. Maybe create a new DS.RelationalAdapter?

I understand this issue might be a bit specific to the server-side technology, but I was just wondering if you guys ever managed to find a solution for this (even custom)? Even with the new {embedded: 'always'} setting on the router, it still does not work as far as I can tell and Ember keeps firing multiple POSTs.

Interested in feature :(

@xamenrax You might want to take a look at the Relational Adapter that @ghempton put together: #724

Very useful. It helped me a lot.


pivotal-medici commented Feb 27, 2013

This has been rebased against master. We're successfully using it in our application, but @tomdale has said it'll need work before it makes it into master. Namely, the mechanism for preserving dirty children needs to be abstracted into the adapter and/or serializer.


ghempton commented Feb 27, 2013

@pivotal-medici this is very similar to #724. We should find a way to combine our efforts.

Alex Kwiatkowski & Ian Lesperance and others added some commits Oct 26, 2012

@elliterate Alex Kwiatkowski & Ian Lesperance + elliterate Delay saving children until parents are ready
Relational databases store the foreign key on the
child. If the parent of a child is new, that
record must be created first before the child can
be saved, as the child needs to know the parent's
primary key.

The DS.RESTAdapter now observes new parents of
dependent children, delaying their committal until
the parent has been created.
@elliterate Ian Lesperance & Robert Gallagher + elliterate Add hook for preserving dirty children on load
This is specifically needed for the REST adapter to ensure that dirty
children are preserved when new parent data comes back from the server.
Because the children are responsible for saving the relationship, the
parent record on the server won't yet know about the children. If the
children are dirty, it means they will be persisted to the server on
their transaction's next commit, at which point the server will then
know about them.

tomdale commented Apr 6, 2013

What's the status of this? Wasn't this fixed?


bradleypriest commented Apr 6, 2013

Nope, this is still an issue in my application. There are two implementations, this one and #724, and hasMany relationships don't really work without using one of them.

wamrewam commented Apr 6, 2013

Just meant to add: this (we use #724 but it is the same idea) has proven extremely useful to us too. It would definitely be fantastic to have it merged. And it has been pretty stable as well.


stefanpenner commented May 20, 2013

closing in favour of: #724

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment