implement support for singleton resources for DS.RESTAdapter #58

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
8 participants

In order to support working with singleton resources, I modified the RESTAdapter to take the different URL scheme into account for that.
While fiddling with the URLs, I also made the calculations of URLs consistent (e.g. deleteRecord used the primaryKey attribute, while all others hard-coded 'id' as primary key)

Defining a singleton resource is pretty easy:

App.User = DS.Model.extend();
App.User.reopenClass({
  isSingleton: true
})

This pull request is by no means complete, since IMO we need to discuss about the API for that.

  • how do i find such a singleton resource? DS.Store doesn't know about singletons, so these don't work:
App.store.find(User) # no ID, no query
App.store.find(User, 1) # but the found user most likely isn't ID 1, so the mapping clientId <=> ID breaks
App.store.findAll(User) # would then return a ModelArray with exactly 1 model. works but sucks

Maybe we should introduce a findFirst() API method to DS.Store and Adapter?

  • how do we cope with the bulk methods? just throw an error?
  • no docs yet (until the other stuff is settled)

Just give me some feedback on how you think it should work, i'll fix that then

Owner

tomdale commented Jan 25, 2012

Instead of introducing a new findFirst() method, it seems like we could support the right behavior for singletons in App.store.find(User).

The way we've been handling this so far has been to give singletons returned from the server the id of singleton, but I think this approach is better. Unfortunately, I think it also means we have to introduce the concept of singletons to the store; trying to fake it in the adapter will lead to an impedance mismatch.

maybe

App.User = DS.SingletonModel.extend();
user = App.store.find(User)

this way, we can cleanly differentiate between singleton and collection models or should we just stick with the boolean attribute?

Using collection methods (findAll, findMany, findQuery) should raise an error

garth commented Feb 16, 2012

I like the idea of using App.store.find(User, 'current') so that you can map to /user/current on the server, but if the json returned does not have current as the id it should be possible to update the clientid with that from the server.

Owner

tomdale commented Apr 26, 2012

After thinking about this for awhile, I'm not sure that we want to pay for the additional code cost for something that can be easily worked around by assigning singletons a standard id, such as singleton or current. It introduces complexity and increases load times without a concomitant benefit.

If there's a use case I'm not understanding, let's continue the discussion here. Otherwise, I think the workaround is just to use standard ids for singletons.

tomdale closed this Apr 26, 2012

This was referenced Sep 22, 2012

Since singleton resources are a useful part of REST, not supporting them in some way seems to impose a constraint on a REST-compliant back-end.

I think that the simplest use case is that a Rails programmer is comfortable about working with single resources. So, having emberjs supporting it out of the box is great. Lots of Rails developers can use it, without worrying how to find workaround for it.

@tomdale I know that the feature dimensions are big, but I recently read your reply about people against services in emberjs: http://discuss.emberjs.com/t/services-a-rumination-on-introducing-a-new-role-into-the-ember-programming-model/4947/30 and why not stand with the same position about singular resources?

I wanted this too.

any progress on retrieving singular resource? Definitely a 'must have' feature

Owner

tomdale commented Jan 29, 2015

@cerdiogenes I'm definitely open to revisiting it. The biggest two areas of concern for me are:

  1. How do you declare that a model is a singleton?
  2. How do you find singleton models? store.find('singleton-type') will do a find all.

Regarding item 2, we've had some discussion about having more explicit finders that don't depend on the type of arguments passed to determine behavior. @igorT, where are we with that?

Member

wecc commented Jan 29, 2015

@tomdale Related to item 2: #2728

Owner

tomdale commented Jan 29, 2015

@wecc Perfect, thank you.

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