belongsTo must have corresponding hasMany, and vice versa

[pharcosyle]

The newest ember-data seems to mandate that every belongsTo relationship has a corresponding hasMany relationship. For example, if I have models like this:

App.User = DS.Model.extend
    name: DS.attr 'string'

App.Note = DS.Model.extend
    author: DS.belongsTo 'App.User'

... and I attempt to set the 'author' of a Note and commit(), I get an exception in OneToManyChange.sync() because it tries to update a 'hasMany' Notes relationship in the User that doesn't exist.

Is there some way to sidestep this behavior?

[wagenet]

Why do you want to?

[pharcosyle]

Here are my models in a bit more detail:

App.User = DS.Model.extend
        name: DS.attr 'string'
    notes: (->
            App.Note.find author: @get('id')
            App.Note.filter (data) =>
                data.get('author.id') is @get('id')
        ).property 'id'

App.Note = DS.Model.extend
    author: DS.belongsTo 'App.User'

So when I ask for a User's notes I perform a query to load them all into the store, and then return a filter that keeps the list up to date in case the user adds any. If I changed this to

App.User = DS.Model.extend
    name: DS.attr 'string'
    notes: DS.hasMany 'App.Note'

The list of the User's notes would be kept up to date as he adds new ones, but any notes that already exist in the database wouldn't be in the list.

[sihingkk]

Hello, I also don't want to be forced to define both side of relation.

For Instance if I have Tag and three others models, which are taggable, I don't want to have to define 3 different list in Tag (tag could have for example 100 000 id's connected to it)

[pharcosyle]

@wingtsun I have a fork of ember-data in which I've removed this functionality, I can share if with you if you like.

[wagenet]

I think this is something @wycats and @tomdale are working on.

[wycats]

@wagenet confirm

[elliterate]

We've submitted an implementation for this with #477.

[pharcosyle]

This still seems to be the case as of revision 11. What's the sitch?

[pharcosyle]

Follow up: as of revison 11 overriding the private _inverseRelationshipFor prevents ember-data from trying to infer any inverses.

DS._inverseRelationshipFor = ->

[sly7-7]

I don't know if this has changed during the last month, but it seems to me that there were a {inverse: null} option available when defining a relationship.
Also, I see something like one_to_none relationship: https://github.com/emberjs/data/blob/master/packages/ember-data/tests/integration/relationships/one_to_none_relationships_test.js So perhaps relationship without inverse just work now...

[igorT]

Relationships without inverses work now. I will soon be adding explicit support for inverse:null, but in most cases it should be plug&play.