First, current guide on models is plain wrong. It describes 0.13, but the download link in the introduction points to latest build from master, which is 1.0-Beta.
Second, I can’t find a 0.14-Build, nor a latest build of a 0.x-Branch (nor a 1.0beta-Build, but one could use master I guess).
Third, and most important: lack of embedded record support is a complete showstopper for us. We use MongoDB-Backend with embedded records without IDs. I don’t see any way to deal with that with 1.0-Beta. Will support be back for 1.0-Final?
Yes, I read the guide. It shows how to map IDs of embedded records into an ID array as relationship property of the parent record. This doesn’t work for me, as my embedded records don’t have IDs.
I’m confused by the document zaius attached. From what I understand the final section Embedded Records appears to explain how to reformat the JSON response so that commentIds are embedded in the post object and comments are on the same level as the post object. If my JSON payload already does this do I need to alter it?
Also in return this._super.apply(this, arguments); where is the arguments variable defined and is necessary.
Ember’s conventions? Maybe you want to think about the meanings of the words embedded and side. Embedded means that the full child record is embedded into the parent record. So yes, you are using side-loaded records. And please create a new topic for further questions if they don’t relate directly to the problem described above.
@rainerfrey - Do you need to reference the sub-objects as separate data objects, or can they just be deserialized into an object property? Is there ever multiple parent objects referring to the same child? Can you paste an example response from your server?
@brayniverse - arguments is a variable defined automatically in every javascript function. It’s an array* of the arguments passed to the function. You don’t have to define it yourself. That return this._super.apply(this, arguments); call means call this method in the parent object with the same arguments that I was called with.
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:
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?
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.
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 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.
no solution for solving the problem.