…will receive any add or remove
…itialize with existing parent models. i.e. it will ignore any models passed as args to the constructor and instead do an internal silent reset.
…t's models from the parent. The idea being that though these models may not belong to this particular subset any longer, they may still belong to another subset. The parent should always contain the superset of models. So when resetting the parent, we look for any models from the new set of models that are missing from the parent and include them. Additionally, when adding a model to a subset's own collection we try and look it up on the parent (so both collections reflect the same instance) and failing that we create a new model instance (if only attributes were added). Updated tests to reflect the multiple subset use case. Note: To avoid the parent's reset event from re-resetting the subset's collection, we mark the event with a 'subset_reset' option. We only act on proxied 'reset' events that don't have this marker. This has the additional benefit of not propagating the parent's (subset initiated) reset event to sibling subsets.
…ttributes change that would make them now fail/pass the sieve. By default subset's will be liveupdated (liveupdate_keys = 'all'). To limit the model keys on which the subset will be liveupdated, set liveupdate_keys to an array of model attributes. liveupdate_keys = ['archived', 'dated_on'].
…arent. All models in the subset should be the same instance as in the parent collection. Corrected test to reflect this.