Ember Data 1.0Beta - embedded records

What do you mean with “serialize into an object property”? It is an embedded one-to-many association, each child record has several properties, number of child records varies, new child records can be added to parent records. Controller code and templates use individual child record model instances to edit these properties and define the order of the records within the parent. In this regard I need to reference these as separate data objects.

A child always has exactly one parent, and is only ever retrieved through that parent, in that regard I don’t need to treat them as independent data objects.

Here’s a sample parent record with 2 child records:

{
  "mailing": {
    "id": "51e4eb7d30042564849b3a36",
    "lastModified": "2013-08-30T08:23:26Z",
    "created": "2013-07-16T06:43:09Z",
    "mailingType": "ORDERCONFIRMATION",
    "active": false,
    "modules": 
    [
      {
        "moduleType": "imprint",
        "description": "Imprint",
        "refId": "52204eab30046bf106250d49",
        "html": "<div class=\"xc-imprint\"><h1 class=\"xc-imprint-h1\">Impressum<\/h1>Beispiel GmbH<br/>Beispielhandelsregistereintrag<br/>Beispielgeschäftsführer<br/><\/div>"
      },
      {
        "description": "Company logo",
        "html": "<img class=\"xc-logo\" src=\"images/templates/xc-transactional/logo.png\"/>",
        "moduleType": "logo",
        "refId": "52204eab30046bf106250d4a"
      }
    ],
  }
}

Now I’m even more confused. The transition guide shows how to deal with embedded records by moving the embedded objects to the side-loaded structure with IDs in the relationship attribute.

The updated model guide explicitly mentions not having/needing IDs as use case for embedded records, though it also says that the adapter needs to be extended to read the embedded structure:

When you have a data structure where the embedded data doesn’t use or need ids, you have to specify that the belongsTo relationship is contained by the hasMany relationship.

To do this, you need to extend the adapter that your app is using to load the data with the embedded structure.

But how would I extend the adapter to support the case when no IDs are used for the child records?

1 Like

You can deserialize the array and just leave them as an array of plain javascript objects. There’s a raw deserializer on the bottom of the transition doc that would work since you’re just using an array of basic objects with string keys. Then you could use DS.attr(‘raw’) for the modules.

Or if you need more functionality on those objects, you could App.Module.create inside a deserialize method.

Since it’s nested objects, serializing may be more work, but I haven’t tried it yet.

Sorry, but this is not getting me anywhere. I have no guarantee that the next embedded model has only string attributes. I also can’t use plain javascript objects, I have controller logic that expects these objects to behave like models. I do need embedded models, and the removal in 1.0.0.beta is a serious regression for me.

What I need is a statement from the ember-data team what the plans for that feature are. I need to decide whether ember-data will be a viable solution for my project in near(ish) future. I can deal with rewrites and incompatible changes, and I don’t need ember-data to be production ready now or in the next few months. But I do need a perspective whether it is going in the direction that I need.

1 Like

Sorry, but I don’t care whether you get anywhere with this or not.

What your asking for is possible. Especially so with the new data rewrite. If you’d like my help with getting something working, I’m happy to offer it. But you’re not entitled to it. And I am guessing you’re not going to get any core members on your side if you make demands without properly explaining your problem.

If you really want to fix it, lose the attitude, and give a clearer explanation of your requirements rather than adding bits on with every post.

I am having a similar issue. This is the related StackOverflow question.

I have the same issue :frowning: no solution for solving the problem.

This would be nice to know if / when the core team planned to handle embedded records without id in ember-data 1.0 beta.

1 Like

I never asked to “get something working”. I asked what the direction of a larger feature is, which I need throughout my application.

I hope this is clear enough now: I want declarative embedded one-to-many relationships, as described in the user guide. I can live with extending the serializer and/or adapter for that, but that should be transparent for the application code.

The provided sample payload is one example, but embedded relationships will be used throughout the application. Therefore this is an important feature for me, I was happy to have it in ember data, and I think it is not unreasonable to ask for an outlook whether it will be back anytime - and if so, possibly before 1.0.

1 Like

I just posted a pull request for adding some basic embedded records support. See https://github.com/emberjs/data/pull/1234

Thanks @ssured, this is a really important feature for me as well.

Everybody else, if you need embedded records support, why not +1 @ssured’s pull request to help put it on the core team’s radar?

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

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.