Sub resources with emberjs + ember-data

Question

So I'm having (what i think is) a general problem w/ Ember-data. I'm wondering how to properly customize the adapter to adapt to the following situation.

Pretend I have two objects: Post and Tag

Calling App.Post.find() returns all the posts by GETing api.com/posts, App.Post.find(1) is found at api.com/posts/1. This is good.

App.Tag.find() will return all the tags that are available at api.com/tags. App.Tag.find(1) will return the appropriate tag at the correct url. Also good.

If I create new Posts via App.Post.createRecord({...}) It will POST to the correct url. The same goes for creating Tags. So far everything is dandy.

Tags on a Post are embedded because they are "on" that post.

App.Adapter.map("App.Post", {
    tags: {embedded: 'always'}
});

During load, Ember-data does everything right and I'm still super happy.

So my problem comes from adding a Tag to a Post. I would like to PUT or POST the tag object to api.com/posts/1/tags where the server will do all the server side things.

Currently,

1. Ember-data, with the {embedded: 'always'} config set, will send a PUT to api.com/posts/1 with the entire Post object (with new Tag object included) as a JSON stringified string.

2. Without the {embedded: 'always'} config set, ember-data will try to PUT the tag object to api.com/tags and will send in the Tag object with a post_id parameter so the server side can do all the server side things.

I'd rather not do 1 because my server isn't set up that way. I'd rather not do 2 because PUT/POST/GETs on api.com/tags should really be for the "Tag management" portion of my application, and not really applying tags to posts. Another example of this behaviour is in the Github v3 API for Labels & Issues.

Does anyone know of a way of handling this with ember-data? Thanks!

Answer 1

You might consider overriding the RESTAdapter#dirtyRecordsForHasManyChange function to manage how the Tags get treated during the transaction.

But it is a bit confusing that you don't have embedded relationships, however you don't want to perform PUT on Tags during Post model relationship changes. I'm not sure I see the problem with out-of-the-box adapter behavior.