[RESTAdapter] Allow new parent, child to be saved at once

[pivotal-medici]

When the relationship branch was merged, it removed the concept of one model "waiting on" another model (via a "pending" state). This means it is no longer possible to commit a new parent and child at the same time, like so:

App.Person = DS.Model.extend({
  name: DS.attr('string'),
  parent: DS.belongsTo('App.Person'),
  children: DS.hasMany('App.Person')
});

parent = store.createRecord(App.Person, {
  name: 'Victor'
});

child = store.createRecord(App.Person, {
  name: 'Alex',
  parent: parent
});

store.commit();

At this point, there will be two people in the database, and (since we're assuming a relational database) we'd expect that the child would have a parent_id equal to parent.id. However, the child's parent_id is actually saved as NULL.

The actual commit of the new child record by the REST adapter needs to wait for the parent's commit to finish so that it can obtain and use the parent's ID.

[sly7-7]

👍 I think there is a more general concept behind this. I would love @wycats, @tomdale or @tchak around this.
In fact, when having create/update/delete of records involved in relations, client and server are potentially not in synch after the different server response. For me it was already the case before the merge with the RI branch.

imagine you modify a parent attribute + add a child. So two requests are send to the server: one for the parent, one for the child. But the server process the parent and answer with no child, then the child (so server-side, the parent has now one child). As a result, after the didSaveRecord, client-side, the parent does not have a child :/

I hope I've been clear...

[tomdale]

Because the notion of dependencies while saving is a fully adapter-level concern, we removed it from the store. Unfortunately, we have not yet had time to add the functionality back into DS.Adapter.

Our long-term plan is to add similar waitingOn semantics as a convenience on the adapter. Your adapter would internally do the book-keeping (by creating a graph of dependencies, let's say) and only acknowledge each record as completed as it was saved.

In the meantime, you are welcome to implement this in your adapter manually. You may want to look at our old implementation for inspiration.

Basically, you would look through each changed record with a changed belongsTo relationship and see if the other side had an ID. If it did, you would save immediately. Otherwise, you would create an observer on the other record's ID, and when it was assigned one, you would trigger the code that attempted to save the child record.

[ekosz]

+1 Just came across this issue now. This feature would be very helpful to have.

[elliterate]

We've added an implementation to our pull request, #440.

[Energiz0r]

+1 Having the same issue here. Would really like this issue to be fixed.

[megpha]

+1 Having the same issue.

[whather]

+1 Same. I assume you're working on a fix for this from the embedded-records branch? Any idea when this will be merged into master?

Thanks!

[thhermansen]

👍 Good work on both ember and ember data. Making this issue work will make it even better :)

[Energiz0r]

Any update on this?
The label of this issue states that it is an improvement but the documentation of Transaction states:

### Asynchronous Commits

Typically, all of the records in a transaction will be committed
together. However, new records that have a dependency on other new
records need to wait for their parent record to be saved and assigned an
ID. In that case, the child record will continue to live in the
transaction until its parent is saved, at which time the transaction will
attempt to commit again.

Should this be a bug, with a 1.0 milestone?

[stefanpenner]

closing in favour of: #724