Check existence of belongsTo without loading

[raytiley]

I'm running into is checking the existence of a relationship without needing to load the relationship. Say I'm rendering a list of something and I want to use a {{#linkTo}} helper if the relationship is not null. if I use {{#if relationship}} than it causes the relationship to be fetched. This causes all the related models to be loaded, even if the user is never going to click them.

A better solution would be to have an attribute that is the key for the relationship and check that, but since the two don't know about each other they can get out of sync which is crappy.

Wondering if anyone else is doing something similar and how your solving it?

[ianpetzer]

I've got the same problem. I need to iterate over a hasMany relationship creating a link for each one. The relationship is not embedded, the server returns the ids of the associated entities.

At the moment, I have an second attribute on the model that just stores the ids of the associated entities and I iterator over that to build up the list. It works for a read-only view of the data but is no good if you're modifying the associations.

A possible solution would be for the belongsTo and hasMany methods to return an object which can respond to an id function call in its own right, but if any other attributes / functions are accessed, it returns the computed property which delegates to the getBelongsTo / getHasMany functions.

Easy to conceptualise.. harder to implement and test

[ebryn]

This is a tricky problem. Right now you could solve it by creating a computed property that looks inside _data to see if there are values. Perhaps we should do some unknownProperty magic to automatically generate has* properties for relationships.

[raytiley]

I like the has* property idea. I'll give a crack at implementing that in the next few days. It should probably also check if there is a cached value for the CP in case its been set with a record that is not reflected in the _data.

[ebryn]

@raytiley Any news?

[raytiley]

I never got around to this. If its still a needed / wanted feature that fits with your plans for EM I could take a crack at it.

[ebryn]

I think it's a good idea to be able to check existence w/o loading.

On Fri, Feb 21, 2014 at 7:19 AM, Ray Tiley notifications@github.com wrote:

I never got around to this. If its still a needed / wanted feature that fits with your plans for EM I could take a crack at it.

Reply to this email directly or view it on GitHubhttps://github.com/ebryn/ember-model/issues/163#issuecomment-35739279 .

[ebryn]

@raytiley ping :)

[garrettlancaster]

I'll also add a :+1: here

[gabriel-dehan]

:+1:

[varblob]

:+1:

[pedrokost]

+1

[garrettlancaster]

:+1:

[esbanarango]

+1 PLEASE!

[Keoven]

:+1:

[voltidev]

:+1:

[chbonser]

Does anyone have a good solution for this with the latest versions (Ember 1.11.3 and Ember Data 1.0.0-beta.16.1)?

Observing model._data.property with those versions results in the following error the next time we reload that object from the server: You must use Ember.set() to set the '...' property.

@stefanpenner asserts observing model._data.property not supported here. If so what is the proper way to do relationship existence checks without loading the object?

[wolfbiter]

+1, my hack of model._data.relPath was broken by the latest ember data :(

versions:

DEBUG: -------------------------------
ember.debug.js:5442 DEBUG: Ember      : 1.13.8
ember.debug.js:5442 DEBUG: Ember Data : 1.13.9
ember.debug.js:5442 DEBUG: Firebase   : 2.2.9
ember.debug.js:5442 DEBUG: EmberFire  : 1.5.0
ember.debug.js:5442 DEBUG: jQuery     : 2.1.4
ember.debug.js:5442 DEBUG: -------------------------------

@chbonser i've updated to now use this, which is ugly but works: 'model._internalModel._relationships.initializedRelationships.${relPath}.inverseRecord.id' (note this is es6 string interpolation)

[bj-mcduck]

+1

[GendelfLugansk]

+1

[bdevel]

If a User and many Messages and you want to know if a Message has been attached to a User, calling message.get('user') always returns a promise (if async=true) but calling message.get('user.id') will either return undefined or the ID of the user without hitting the server.

The message has the ID for the User as one of it's properties so it doesn't need to go fetch it.

[chvonrohr]

:+1: