Stumped on save behavior using belongsTo about emberfire HOT 10 CLOSED

@brancusi I'll try to take a look this week. Thanks for all the context!

from emberfire.

I also had this issue and taking out the belongsTo fixed it for now.

For #2, I think that you can just do item.get('conversions').then(function() {...})

from emberfire.

I'm having the exact same problem, with the exact same "fix." I'm new to the library as of today (coming from Fireplace), but I imagine this has to be a relatively new bug (assuming that's what it is), given that this is a pretty common scenario that wouldn't have gone unnoticed all the way to a 1.x.x release. It took me all of an hour to run into it. Let me know if I can help try out different scenarios.

from emberfire.

I should ask, is it more idiomatic to set the belongsTo objects when creating those records (item and unit on the conversion record) and before doing the addObject, like in @brancusi's example? Or to create the record without them, do the addObject, and then all the saves last? Both approaches seem to give identical results.

from emberfire.

The problem is in ember-data's JSONSerializer here. The only types of relationships that it serializes (1.0.0-beta7) are manyToNone (which is why it works when you drop the belongsTo) and manyToMany. Without the serialized JSON, you won't get the saved references. I don't know if it has always been like this without searching though the commits.

from emberfire.

According to the notes on the commit for this method, it was the intention of the developers that you would have to override it if you needed to save the ids on the hasMany side. We're not the first to be surprised. It looks like emberfire will have to override this method.

from emberfire.

@neverfox nice find! Thank you!

from emberfire.

You're welcome. I was in a bind myself, so I needed it to work. Hopefully, the pull request I submitted is acceptable.

from emberfire.

I hope so too.

from emberfire.

Works thank you!

from emberfire.