-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How important is it to have an explicit reverse relation support? #51
Comments
I am currently porting a very big app from BB relational to BB associations. We made very heavy use of reverseRelation so I will let you know if I have some use case where I am blocked with current BB assocations implementation. I will work on this next week. |
I would recommend you use the edge version. We are about to release v0.5.1. You can read about the upcoming features in the changelog With that out of the way: Thanks for your appreciation! I am excited to hear about your real-world experiences during your port to BB-Associations and whether reverse relations can be avoided! If it goes successfully, it would be nice if you could share your recipes and experiences - so that I could include it in our documentation. |
I still have some regressions due to BB Relational cache removal, but migration seems to be mostly successful. Your sample on this issue was really helpful, and should be integrated in documentation if it is not. I will keep you inform when all migration bugs will be fixed. BB associations is a pleasure to use so far. |
We plan to integrate BB Assocations in our upcoming of RESThub stack (http://resthub.org/), can you tell me when 0.5.1 release is expected ? |
From the perspective of code, we are ready. I just need to update the CDNs and the documentation. So I would say a couple of days - at most. I am really happy to hear that the migration has been mostly smooth so far! Based on your experiences, I would like to put in a upgrading from BB-Relational section. The example in this issue and whatever problems you share will find it's way into that documentation. |
v0.5.1 is now released. The documentation has been updated with your suggestions. I am going to wait till you finish your port to BB-Associations before I write a "porting from BB-Relational" section. It would be nice if I could also link to http://resthub.org on our website. It's always great to see a complete stack implementation! |
Nice, thanks. I have updated our snapshot documentation at http://resthub.org/reference/snapshot/backbone-stack.html, we just have access problem to the website as described on #53 issue. |
I think we have found an issue while porting our big application from Backbone Relational to Backbone Associations. The issue is the following, I have a Parent - Child relation like following : var Record = Backbone.AssociatedModel.extend({
relations: [{
type : Backbone.Many,
key: 'childrenMinders',
relatedModel: ChildMinder,
collectionType : ChildrenMinders
}]
}
var ChildMinder = Backbone.AssociatedModel.extend({
relations : [{
type: Backbone.One,
key: 'record',
relatedModel: Record
}]
} When we serialize Record we have something like this { id: 2,
name: 'test1',
childrenMinders: [
{id: 1, type: 'test1'},
{id: 2, type: 'test2'},
{id: 3, type: 'test3'}]
} Based on our server requirement, we need something more like this, with the backreference from ChildMinder to Record provided (only this id) : { id: 2,
name: 'test1',
childrenMinders: [
{id: 1, type: 'test1', record: { id: 2},
{id: 2, type: 'test2', record: { id: 2}},
{id: 3, type: 'test3', record: { id: 2}}]
} Is it currently possible with Backbone Associations or any improvement possible to support such use case ? |
@dhruvaray Thanks for your test case. It works but I am a little puzzled by the need to add the findRecordById logic to each model where I have this kind of relations. Could you explain when occur different cases :
Anyway, I understand that since we do not have a store like in BB relational, we have to implement Record retrievable, but for simple case (1), isn't it something that could be manage by Backbone Associations automatically without exposing "internals" like the one implemented in findRecordById + map attribute definition ? |
I put conditions 2 & 3 to just demonstrate various serialization options. You could trim as per your requirements
{ id: 2,
name: 'test1',
childrenMinders: [
{id: 1, type: 'test1', record: { id: 2},
}
{ id: 2,
name: 'test1',
childrenMinders: [
{id: 1, type: 'test1', record: 2},
}
Because a map function has been specified, the framework will call the map function to transform the passed value before proceeding. Hence the need to handle all the scenarios. However, practically speaking, you would typically be passing only ids around for Models.Record. (As it is probably a shared application entity and referred in multiple places) Consequently, the test case can be simplified to findRecordById:function (val) {
return _.findWhere(MyApp.Context.provinceRecords, {id:val.id});
} See 9a96972 for the updated test case. I hope this makes things clear. |
@sdeleuze : I just now made a change - b8257a8 - which should handle the common (cyclic) scenario transparently. With this change, you don't need to over-ride the toJSON method for cycle scenarios or pass options to save(/fetch/set) methods. With this change, you can use BB-Associations to do exactly what you wanted here - without any special application handling. |
@sdeleuze, others : As an FYI : Our recently released Backbone Eye - a tool to analyze and understand Backbone application behavior without debugging Javascript - also plays well with Backbone Associations (and other nested frameworks as well). The above example would graphically pan out like this in our tool. Would love to see folks take this tool for a spin! |
Thanks a lot, I am going to try this improvement |
I would find implicit reverse relations quite useful, in my app I use requirejs to load each "class", when defining a reverse relation each relation definition needs to specify the related model which causes a circular dependency. I can provide an example if needed. |
@mattcroberts : You can specify the circular dependency in requirejs as shown in #74. Is that the only reason you would want implicit reverse relations? |
I've created a gist to demonstrate what I'm trying to do and with the approach you linked to which hasn't worked for me. |
Here's the working version of your gist : https://gist.github.com/dhruvaray/6929867 return require("Person"); //and return require("House"); in `House` and `Person` respectively. |
Since I've been mentioning reverse relations in #88 and #91, I figured I'd add my thoughts to this thread.
The question about ambiguity & coupling is a good one. Actually, I think ambiguity's not a huge issue, that can be handled through appropriate warnings should an attempt be made to define two relationships with the same name. Coupling is admittedly somewhat disturbing; but I think the coupling is there because semantically the models really are coupled. On that last point, I'm somewhat thinking these days that the declaration of a relationship between to models shouldn't be in either of the model's definitions. In fact in my own app I'm on my way to making a bidirectional-relation definition along the lines of:
which in turn does:
and also with some hooks to create event listeners that will update one direction from the other automatically, plus setting up JSON serialization, store-lookup/mapping, etc. |
BB Associations supports reverse (inverse) relationships implicitly - via the parents property. Do users of BB Associations see a value in supporting explicit reverse relations - in the style of Backbone-relational?
can also be simply modeled as
Would be nice to see an example of what explicit reverse relation support could bring to the table.
EDIT : 19th July
Also, reverse relations like the one defined in BB-Relational can cause ambiguity and coupling between model definitions.
For example
The text was updated successfully, but these errors were encountered: