(Edit: Oops, I take too long to write. I wrote this out before seeing your second reply above.)
--
Oh -- I completely misread your original post. Sorry about that; totally my fault.
I think you're completely right about it seeing the ID of a player model it already knows about, and inserting that one.
This is due to the model.store itself: whenever you instantiate a model, canjs checks the model.store to see whether an instance already exists with that primary id. If so, it applies the new attributes to the existing model and then returns that original model instance -- so you'll always end up with multiple references to the same model instance, instead of multiple instances claiming to represent the same entity. (So long as the store doesn't garbage-collect the model instances, at least.)
This behavior comes from the model constructor itself -- it's not affected by attributes, or nesting, or the method you use to load the data.
In this case, the 'correct' result is that canjs gives you a player->team->player infinite loop: otherwise, you'd have two separate objects both claiming to represent Player #1, and from there you'd run into issues any time you try to update an attribute, bind a handler, delete the model, etc.
The only workaround I know of is to define a completely new class for the nested Players -- a new model class will get its own store -- but if you're going to be creating, updating, or deleting anything in that nested data then you'll have to keep the 'root' Players in sync manually.
--
Oh -- I completely misread your original post. Sorry about that; totally my fault.
I think you're completely right about it seeing the ID of a player model it already knows about, and inserting that one.
This is due to the model.store itself: whenever you instantiate a model, canjs checks the model.store to see whether an instance already exists with that primary id. If so, it applies the new attributes to the existing model and then returns that original model instance -- so you'll always end up with multiple references to the same model instance, instead of multiple instances claiming to represent the same entity. (So long as the store doesn't garbage-collect the model instances, at least.)
This behavior comes from the model constructor itself -- it's not affected by attributes, or nesting, or the method you use to load the data.
In this case, the 'correct' result is that canjs gives you a player->team->player infinite loop: otherwise, you'd have two separate objects both claiming to represent Player #1, and from there you'd run into issues any time you try to update an attribute, bind a handler, delete the model, etc.
The only workaround I know of is to define a completely new class for the nested Players -- a new model class will get its own store -- but if you're going to be creating, updating, or deleting anything in that nested data then you'll have to keep the 'root' Players in sync manually.