In the register method, it checks if the model already exists in the collection and then throws an error if it does. I was having trouble with this as it caused my code to break, so I instead make it remove the old model if it's there, then it adds the new one just fine.
Made small fix in register function - if model is already in collecti…
…on, remove old one, so new one can be added.
Have you tried using YourModel.findOrCreate to avoid the error?
I'm using the newest version, that one has the code fix for that, I already read that issue. This happens when I create a new object on the front end, call the save method, and then do a navigate call on it's new id to take you to it's show page. At some point in that process, something calls the register function and it breaks while checking the collection for the model in register(). I don't really ever have a chance to findOrCreate it in the workflow between the save and the successful navigate. I suppose I could try putting it right before the save call, but why should I do that? It seems kind of hacky.
Why do you throw the error in the first place? I'm sure there is a good reason, but I don't know what it is.
This check is there to enforce there will only be one version of a model with a certain id at any given time (which is also the reason for the existence of Backbone.Relational.Store). This is necessary to enforce consistency and integrity of relations.
If we were to allow multiple versions, inadvertently manipulating or performing a save, destroy or whatever on another version of that model (which is still around on the client, and can for example still be bound to one or more views in your application, either on purpose or inadvertently) would save it's state to the server, killing it's relations, and the server response would set the same (incorrect) data on the 'current' version of the model on the client. By then, you'd be screwed.
Therefore, Backbone-relational simply does not allow this situation to occur. I think this is much safer than putting the burden on the user to always make sure every older version of a model is completely decoupled from every other part of your application. It might be annoying to get an error every now and then, and sometimes inconvenient to have to use a factory method like findOrCreate, but it's much better than subtle bugs that can lead to major data loss later on in the life cycle of your application.