This is happening because nothing on the page binds an event listener to the models, so canjs garbage-collects them and removes them from the model.store -- but the objects themselves still have a reference from the console, so the browser doesn't garbage-collect them.
If you bind something to the models, the associations will stay around. Here's the fiddle with some 'fake' bindings added via the models' constructors: jsfiddle.net/qYdwR/777/
I think this can also be solved by immediately rendering all the data with live binding, or handing the model to a control with templated event handlers, but I haven't tested it to be sure.
We ran into this issue often enough that we put in a global workaround: as soon as any data is loaded, we set up a 'fake' binding on it (to prevent garbage collection from the model.store) and then set a timeout to remove that binding a little later. That way, we're guaranteed that the data won't immediately get garbage-collected if we're waiting for something -- and, if we truly don't need it, it'll still get freed eventually. It's messy, but I haven't found any other way.
If you bind something to the models, the associations will stay around. Here's the fiddle with some 'fake' bindings added via the models' constructors: jsfiddle.net/qYdwR/777/
I think this can also be solved by immediately rendering all the data with live binding, or handing the model to a control with templated event handlers, but I haven't tested it to be sure.
We ran into this issue often enough that we put in a global workaround: as soon as any data is loaded, we set up a 'fake' binding on it (to prevent garbage collection from the model.store) and then set a timeout to remove that binding a little later. That way, we're guaranteed that the data won't immediately get garbage-collected if we're waiting for something -- and, if we truly don't need it, it'll still get freed eventually. It's messy, but I haven't found any other way.