relation should be able to get content from model attribute different then 'key'

[4vanger]

I'm having model like

var SomeModel = Backbone.RelationalModel.extend({
    relations: [
        {
            type: "HasOne",
            key: "item",
            relatedModel: 'ItemModel'
        }
    ]
});

Then I init this model with following JSON:

{
  id: 128,
  itemId: 356
}

So relation key is different from an attribute where ID is stored.
But I still want to keep relations - so when I change itemId - item will change. And vice versa - when I change item.id I'd like to update itemId attribute
What's the best way to get this behavior? I'm thinking on creating new Relation type that will have keyContentsAttribute option that will specify which model attribute to use. Is there better approach?

[PaulUithol]

Why do you want this, instead of just using itemId as the relation key (or using item in the data)?

[4vanger]

to differentiate ID field (named itemId) from Model field (item).
Having such conventions for API makes it more predictable - you know when you see 'itemId' - it is an integer reference for Item model. And when you have 'item' in API - you know that it a model itself
In general - thanks for a great lib.

[arjes]

+1 for this.

I am working with a rails backend, and by convention they provide the id in the _id field (or _ids for a many), while the models themselves come via <key>

Its a great lib, I am working on a more Rails like interface to put above it, and I am going to try monkey patching it to get the desired behavior.

[PaulUithol]

Okay, sounds like a good feature to me and I have some time to do this. Would serializationKey be a good name for the option, or does anyone have another proposal? The behavior would be along the following lines:

1. When data gets loaded (basically, on set), the contents of the serializationKey are used as the keyContents for a relation.
2. The client application uses the regular key attribute to interface with the relation and the models in it; the serializationKey is not available as an attribute for the model.
3. When calling toJSON, the includeInJSON options are applied to key, and the results are assigned to the serializationKey.

[4vanger]

As for me "serializationKey" is somewhat opposite to original case (deserialization) and also is too long to type.
What about "keyValue", "keySource", "keyDestination"

[PaulUithol]

Hmm.. keyValue is a bit too generic for my taste (and you usually have a key that points to a value). Source and destination suffer from the same problem as serializationKey; both indicate just one use as well (either deserialization or serialization). Maybe serverKey/keyServer (as opposed to the one the client uses)? Although I do like keySource as well, despite mainly indicating deserialization.

[PaulUithol]

I think I like keySource best, actually. In any case, you'll always be deserializing your app from some datasource to start out with.