-
Notifications
You must be signed in to change notification settings - Fork 37
Firing dissociate events on collection reset #24
Comments
I put a hack in place to fire the disassociate Events on a reset manually for every .one() assoc with an inverse .many():
It works as expected now. |
Hi @pschyska! Thanks for reporting this. You're right, this is definitely a bug. I originally punted on it because Backbone doesn't provide any information about the previous models in a collection. In fact, there is still an open issue describing it. The main issue is that Supermodel will now have to provide a collection implementation and require you to inherit from it. I'll give this some thought and then take a stab at fixing it. |
Exactly, I had troubles to implement it in Supermodel's source directly because backbone provides no "preReset" event.
I realize that you might want to go another way, justsayin :-) A Collection implementation would also make it possible to refactor this model function boilerplate
... by providing a default implementation which does exactly this when saying
|
I just read another referenced Issue with this and the comment given by @wookiehangover also applies to our case, I guess jashkenas/backbone#1521 (comment). When models are members of multiple collections (http://jsfiddle.net/wookiehangover/xCgNu/), and one of the collections is reset, it might not be the right thing to disassociate the models. Maybe it should be done on fetch() only? Because fetch() result should be the canonical representation of this collection, and when there are some models missing in there it's safe do dissociate them. Or, a clear warning about overlapping collections and dissociation in the documentation :-) |
Hey,
I have the following relationships
In the Events resource, Shifts are referred to by shift_ids. When I reload the Events resource, and there are new events, they are properly associated to existing Shift models where the shift_id matches (I suppose the "associate" event gets fired).
When Events are missing though, there is no corresponding "dissociate" event fired, and the Shifts are not informed about Events needing dissociation.
What happens is that in my Events collection, and also in Foo.Models.Event._all, the Events that were missing from the last GET are not present.
However, the Event models are still present on the Shift models (via Shift.events()).
Note: The events are not nested within the Shifts in my JSON in this scenario. They are completely separate resources and we rely on Supermodel's association magic here.
Maybe one could
I read some source code but I'm not sure where to attack this :-)
Thanks,
Paul
The text was updated successfully, but these errors were encountered: