Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Failing unit test about multiple instantiation (shouldn't fail) #180
This (new) test fails but shouldn't on the latest master.
I'd say it should be 1, since this gives the most deterministic behavior. Otherwise, you're always going to have employees (or other relations) jumping ship when you don't expect them to.
This has broken our app.
I've not fully pinned down the issue, but its something like:
Package hasMany Assets
Fetching package returns an array of asset ids:
In a view, I do
and the resulting call stack:
Sorry about the line numbers - backbone-rel's built into a single JS file with other dependencies. I've added a couple reference points to the last two stack points.
I'll see if I can distill this down to a cleaner case.
Ah, my Assets array for the failing object has duplicates:
The issue with throwing an error is that in a case like this, I can't catch the error and continue fetching related.
So, may want to think about throwing the error a bit more - perhaps a warning. Or some option to not throw.
Well, sounds to me like raising this error helped you discover an error in your data early, which could cause more serious (and harder to track down) problems down the line? I'd say that's a good thing.
However, I do agree we could be a bit more forgiving in
A warning might have as well, but yes, you're right.
I do think that the situation with Backbone's not allowing multiple objects in a collection is not really analogous to the situation here because the collections in question in Backbone are ones that the user has total control over, and the collections in question in Backbone-Relational are ones that the user does not really have any control over.
I need to think about it a bit more and see if I can come up with any plausible use cases.
The change in fetchRelated might be a nice hardening thing.