# Ember Data 1.0Beta - embedded records

**URL:** <https://discuss.emberjs.com/t/ember-data-1-0beta-embedded-records/2359>\
**Category:** Ember Data\
**Created:** [September 2, 2013, 7:20am UTC](https://discuss.emberjs.com/t/ember-data-1-0beta-embedded-records/2359 "2013-09-02T07:20:17Z")\
**Posts on this page:** 9\
**Page:** 2

<div class="post-metadata">

**Author:** ![topherdavis](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/topherdavis/32/4862_2.png) [@topherdavis](https://discuss.emberjs.com/u/topherdavis)\
**Post date:** [September 27, 2013, 6:29pm UTC](https://discuss.emberjs.com/t/ember-data-1-0beta-embedded-records/2359/21 "2013-09-27T18:29:45Z")

</div>

Does anyone know if there is a timeline on this?

---

<div class="post-metadata">

**Author:** ![sammy007](https://avatars.discourse-cdn.com/v4/letter/s/2acd7d/32.png) [@sammy007](https://discuss.emberjs.com/u/sammy007)\
**Post date:** [October 29, 2013, 2:27pm UTC](https://discuss.emberjs.com/t/ember-data-1-0beta-embedded-records/2359/22 "2013-10-29T14:27:10Z")

</div>

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](https://github.com/emberjs/data/pull/1234#issuecomment-27305845)

---

<div class="post-metadata">

**Author:** ![ulisesrmzroche](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/ulisesrmzroche/32/11317_2.png) [@ulisesrmzroche](https://discuss.emberjs.com/u/ulisesrmzroche)\
**Post date:** [October 29, 2013, 3:52pm UTC](https://discuss.emberjs.com/t/ember-data-1-0beta-embedded-records/2359/23 "2013-10-29T15:52:45Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![sammy007](https://avatars.discourse-cdn.com/v4/letter/s/2acd7d/32.png) [@sammy007](https://discuss.emberjs.com/u/sammy007)\
**Post date:** [October 29, 2013, 4:34pm UTC](https://discuss.emberjs.com/t/ember-data-1-0beta-embedded-records/2359/24 "2013-10-29T16:34:40Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ulisesrmzroche](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/ulisesrmzroche/32/11317_2.png) [@ulisesrmzroche](https://discuss.emberjs.com/u/ulisesrmzroche)\
**Post date:** [October 29, 2013, 5:25pm UTC](https://discuss.emberjs.com/t/ember-data-1-0beta-embedded-records/2359/25 "2013-10-29T17:25:21Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![beku8](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/beku8/32/15401_2.png) [@beku8](https://discuss.emberjs.com/u/beku8)\
**Post date:** [January 4, 2014, 8:24am UTC](https://discuss.emberjs.com/t/ember-data-1-0beta-embedded-records/2359/26 "2014-01-04T08:24:01Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![pixelhandler](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/pixelhandler/32/18649_2.png) [@pixelhandler](https://discuss.emberjs.com/u/pixelhandler)\
**Post date:** [January 7, 2014, 6:10pm UTC](https://discuss.emberjs.com/t/ember-data-1-0beta-embedded-records/2359/27 "2014-01-07T18:10:06Z")

</div>

@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](https://github.com/pixelhandler/ember-data-extensions) and [docs here](http://pixelhandler.github.io/ember-data-extensions/docs/classes/DS.EmbeddedMixin.html)

---

<div class="post-metadata">

**Author:** ![elsurudo](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/elsurudo/32/15420_2.png) [@elsurudo](https://discuss.emberjs.com/u/elsurudo)\
**Post date:** [January 13, 2014, 11:08am UTC](https://discuss.emberjs.com/t/ember-data-1-0beta-embedded-records/2359/28 "2014-01-13T11:08:31Z")

</div>

@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?](http://discuss.emberjs.com/t/embeddedrecordsmixin-and-ds-store-pushpayload/3806)

---

<div class="post-metadata">

**Author:** ![gonvaled](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/gonvaled/32/14568_2.png) [@gonvaled](https://discuss.emberjs.com/u/gonvaled)\
**Post date:** [February 14, 2014, 1:32pm UTC](https://discuss.emberjs.com/t/ember-data-1-0beta-embedded-records/2359/29 "2014-02-14T13:32:18Z")

</div>

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:

> <https://stackoverflow.com/questions/21750182/choose-character-as-field-separator-in-ember-to-avoid-conflicts-with-library-in>

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 `§`.

Contras:

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

Pros:

- 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.

[Previous page](https://discuss.emberjs.com/t/ember-data-1-0beta-embedded-records/2359.md?page=1)
