Question: Embedded Documents

[dev-inigmas]

What is the correct (and simplest) means of notifying EPF about Embedded Documents? Earlier, I thought that I had figured it out; but now, I'm running into the follow issue:

SO.Foo = Ep.Model.extend
  ### Properties ###
  name:        Ep.attr 'string'
  description: Ep.attr 'string'

  ### Relationships ###
  bars: Ep.hasMany 'bar'

  ### Computed ###
  summary: ( ->
    @get('bars').mapProperty('name').join(', ')
  ).property('bars.@each.name')

SO.FooSerializer = SO.ApplicationSerializer.extend
  properties:
    bars: embedded: 'always'

SO.Bar = Ep.Model.extend
  ### Properties ###
  name: Ep.attr 'string'

  ## Parent Document
  foo: Ep.belongsTo 'foo', inverse: 'bars'

SO.FooIndexRoute = Ember.Route.extend
  model: -> @session.query 'foo'

When going to the "foo.index" route, I get the following:

Error while processing route: foo.index Cannot read property 'isEqual' of undefined TypeError: Cannot read property 'isEqual' of undefined
    at Ep.ModelArray.Ember.ArrayProxy.extend.removeObject (http://bebop.local:9494/dist/deps.js:73508:34)
    at apply (http://bebop.local:9494/dist/deps.js:31391:27)
    at superWrapper (http://bebop.local:9494/dist/deps.js:30969:15)
    at null.<anonymous> (http://bebop.local:9494/dist/deps.js:74282:50)
    at Ep.Model.reopen.suspendRelationshipObservers (http://bebop.local:9494/dist/deps.js:73210:37)
    at Ep.InverseManager.Ember.Object.extend._removeFromInverse (http://bebop.local:9494/dist/deps.js:74280:23)
    at Ep.InverseManager.Ember.Object.extend.unregisterRelationship (http://bebop.local:9494/dist/deps.js:74261:26)
    at null.<anonymous> (http://bebop.local:9494/dist/deps.js:74234:30)
    at Mixin.create.forEach (http://bebop.local:9494/dist/deps.js:39783:20)
    at null.<anonymous> (http://bebop.local:9494/dist/deps.js:74233:37) 

Anyone know what's going on?

Fyi - things seem to load fine when I don't specify an inverse. But then, EPF tries to POST/PUT the embedded document(s) separately.

Thanks.

[ghempton]

Are you using recent build from master?

[ghempton]

You also shouldn't need to specify an inverse in this case

[ghempton]

Also, what does SO.ApplicationSerializer look like?

[dev-inigmas]

I just checked out EPF and built it from the master branch yesterday.

I agree that I shouldn't have to specify an explicit inverse in this case. On another model, doing that seemed to prevent EPF from sending invalid POSTs/PUTs.

Here's the code:

SO.ApplicationSerializer = Ep.ActiveModelSerializer.extend()

[ghempton]

Can you paste an example payload?

On Thu, Jul 10, 2014 at 5:23 PM, David Patrick notifications@github.com
wrote:

I just checked out EPF and built it from the master branch yesterday.

I agree that I shouldn't have to specify an explicit inverse in this
case. On another model, doing that seemed to prevent EPF from sending
invalid POSTs/PUTs.

Here's the code:

SO.ApplicationSerializer = Ep.ActiveModelSerializer.extend()

—
Reply to this email directly or view it on GitHub
#140 (comment).

Gordon L. Hempton
http://codebrief.com
360.460.8098

[dev-inigmas]

Which payload? A GET response? The POST/PUT requests?

[ghempton]

GET response, or both?

On Thu, Jul 10, 2014 at 5:24 PM, David Patrick notifications@github.com
wrote:

Which payload? A GET response? The POST/PUT requests?

—
Reply to this email directly or view it on GitHub
#140 (comment).

Gordon L. Hempton
http://codebrief.com
360.460.8098

[dev-inigmas]

Seems like the explicit inverse doesn't break "findById" requests.... I'll get the responses now.

[dev-inigmas]

Here's a response for a single item:

{
  "race": {
    "doc_meta": {
      "created":1405024824835,
      "updated":1405029317207,
      "created_by":"53bd768f970000004057a9f4"
    },
    "id":"53befa38970000ff7257aa18",
    "name":"qwe",
    "description":"qwe",
    "abilities": [{
      "ability":"qwe",
      "description":"qwe"
    }],
    "module_id":"53bef0b0970000771f57aa17"
  }
}

[ghempton]

Hmm, I think this might be caused by the nested ability not having and id.
Can you try passing a fixed id property just to check if this is the case?
There isn't a real reason why EPF would require an id in an embedded model,
but it could be a bug.

On Thu, Jul 10, 2014 at 5:31 PM, David Patrick notifications@github.com
wrote:

Here's a response for a single item:

{
"race": {
"doc_meta": {
"created":1405024824835,
"updated":1405029317207,
"created_by":"53bd768f970000004057a9f4"
},
"id":"53befa38970000ff7257aa18",
"name":"qwe",
"description":"qwe",
"abilities": [{
"ability":"qwe",
"description":"qwe"
}],
"module_id":"53bef0b0970000771f57aa17"
}
}

—
Reply to this email directly or view it on GitHub
#140 (comment).

Gordon L. Hempton
http://codebrief.com
360.460.8098

[dev-inigmas]

Here is a very truncated response from the server during a @session.query 'race':

{
  "races": [{
    "doc_meta": {
      "created":1377814485629,
      "updated":1394501556095,
      "created_by":"50c923c6e4b0add373778525"
    },
    "id":"50ea5298e4b0c6e36078e0aa",
    "name":"Android",
    "description":"Androids...",
    "abilities": [{
      "ability":"Recharge",
      "description":"During..."
    }, {
      "ability":"Unnatural",
      "description":"Arcane powers..."
    }],
    "module_id":"50c9277de4b0add373778527"
  }]
}

[dev-inigmas]

Putting a static "id" of 1 in there made the exceptions go away. But the abilities also went away.

[ghempton]

Ah so I think the issue is that the abilities have a belongsTo on them.
When this is the case it epf currently expects the ability to have the
parent id specified in their payload, e.g. race_id: '50ea5298e4b0c6e36078e0aa'.
This definitely seems like an area that could be improved.

On Thu, Jul 10, 2014 at 5:56 PM, David Patrick notifications@github.com
wrote:

Putting a static "id" of 1 in there made the exceptions go away. But the
abilities also went away.

—
Reply to this email directly or view it on GitHub
#140 (comment).

Gordon L. Hempton
http://codebrief.com
360.460.8098

[ghempton]

Have you tried removing the belongsTo entirely from the ability?a

On Thu, Jul 10, 2014 at 5:56 PM, David Patrick notifications@github.com
wrote:

Putting a static "id" of 1 in there made the exceptions go away. But the
abilities also went away.

—
Reply to this email directly or view it on GitHub
#140 (comment).

Gordon L. Hempton
http://codebrief.com
360.460.8098

[dev-inigmas]

Yeah; then I get extra POST/PUT from EPF.