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();
This pull request is by no means complete, since IMO we need to discuss about the API for that.
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?
Just give me some feedback on how you think it should work, i'll fix that then
implement support for singleton resources for DS.RESTAdapter
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.
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
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.
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.
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
@cerdiogenes I'm definitely open to revisiting it. The biggest two areas of concern for me are:
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?
@tomdale Related to item 2: #2728
@wecc Perfect, thank you.