Ember Data 1.0Beta - embedded records

Does anyone know if there is a timeline on this?

I believe core team has plans for this. Otherwise ember-data is near useless for applications backed by nosql databases like mongo and couch where embedded objects are first class citizens.

My thoughts about ID-less embedded objects https://github.com/emberjs/data/pull/1234#issuecomment-27305845

No, I wouldn’t call it useless. That’s going too far. To counter, I’m using ember-data with MongoDB just fine by choosing not to sub-populate documents yet. Ember data resolves relationships the other way too: just using id’s. Also, I had previously modified the adapter to support embedded relationships, before I made that decision, so you can do that too.

That is why I say “near”. With compromise or workaround it’s ok. And it’s cool that ED got some attention recently.

PS: all these Store#createRecord reminds me that ember-data tied to ActiveRecord-like backends.

I’d say more like it takes you a long way. You can run a full-scale app using ember-data and mongo. I don’t know how that is near useless. That’s just too much of a hyperbole to me.

I’ve started mongo backend project too. Now I’m having problems with how to add sub-domain computed properties. Is there anyway I can sneak into your adapter code?

@rainer​frey I forked the DS.EmbeddedRecordsMixin to add additional support for embedded objects if you’re still interested checkout the repo… ember-data-extensions and docs here

@pixelhandler How does your fork differ from what is included with Ember Data now?

I’m having trouble getting even the regular EmbeddedRecordsMixin working… wondering if you could give me a hand here: EmbeddedRecordsMixin and DS.Store.pushPayload?

For those of you who are able to tinker with the backend (and dont’t care about the extra penalty in performance), you can use the following approach to make your documents compatible with ember-data:

The trick is to flatten/deflatten the documents on the server, using a special character as separator. This is working fine for me, with separator §.


  • overhead and extra complication in the backend.
  • Risk of data corruption if flattening/deflattening is not properly implemented.


  • no need to fork ember-data
  • no need to wait for support for structured documents (which will probably never come?)
  • by feeding ember-data with the one-and-only format that it is supporting out of the box, we can avoid the baroque configuration process

I have even added a propertyMapper in my backend, so that I am feeding ember-data not only a flattened document, but also the properties exactly as it is expecting them (no more underscore mangling surprises), so now I can avoid most configuration for ember-data. My application complexity has decresed notably. The backend (python) changes have been roughly 200 lines for all property mappings and flattening, centralized in one place and easy to modify if I need to. The frontend has lost >500 lines of configuration scattered around dozens of models.