New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no 'fetched' event on model when collection is loaded #241
Comments
yeah, I met the same problem as yours.. fetch: function(options) {
options = options || {};
var forModel = options['each'];
return db.Collection.__super__fetch.call(this, options)
.then(function(collection) {
return collection.invokeThen('fetch', forModel)
.then(function () {
return collection;
});
});
} |
Right now @fritx your method is going to create @bogus34 If you can share what you're actually doing in your |
yeah, thanks @bendrucker, you alarmed me.. |
Hey @bendrucker, // db.Model
fetch: function(options){
if (options['free']) return Promise.resolve(this);
return db.Model.__super__.fetch.call(this, options);
}
// db.Collection
fetch: function(options){
options = options || {};
var forModel = options['each'];
forModel['free'] = true;
return db.Collection.__super__.fetch.call(this, options)
.then(function(collection) {
return collection.invokeThen('fetch', forModel)
.then(function () {
return collection;
});
});
} |
I'm convinced that we have to threat fetching a collection just as an another way to fetch a model. After all when I fetch a collection I got a model that was retrieved from database. I'm just inspecting and planing so I haven't REAL example. But @fritx have. Maybe I want to implement a sort of id-based cache. So when model is fetched I put it to cache so I can take it back in future. Simplest idea to implemment this is to hook into fetched event. But next in some point I'll use Collection to get a bunch of models and everething goes wrong. Btw, collection may be used implicitly if I load my model in context of relation. |
A collection is a convenient way to populate and manage a group of models, but not doing operations on each model is pretty consistently implemented. You have @fritx While that will work, I recommend against it. It's not a good idea to have And yes, if you add custom collection behavior you'd need to use that collection explicitly in relations where the model is on the right side of an n-to-many relationship rather than allowing a collection to be implicitly created from the model. It would be really helpful to see actual code here. Firing |
To summarize. My main point is that Model is actually fetched from database even if it is loaded by Collection. So it looks logical if it will fire apropriate events. Your opposit point is that firing many events may lead to a performance problems. Am I correct? Thank you! |
Roughly correct. There's performance issue, but also the general principle that it's way easier for you to add custom behavior than to strip out something we enforce. If a Whereas if you want to add in this behavior, it's easy. Here's how you and @fritx should be doing it: collection.fetch()
.then(function (collection) {
return collection.models;
})
.map(function (model) {
return model.triggerThen('fetched');
})
.return(collection); See the Bluebird API docs for more on functional programming w/ promises. You should make sure your |
Yes, that makes sense. Thank you! |
You got it! I highly recommend taking a 15 min read through with the Bluebird API. It's a really amazing library and functional transformations (maps, filters, reducers, etc.) of promises can be extremely powerful. |
It makes sense. Thanks! |
Is it possible to override the query builder at |
Maybe it will be practical if 'fetched' event were fired on each model loaded in collection.
Say if I have model User and collection Users. And User has some special logic in its 'fetched' handler. When I call Users().fetch() this logic is simply skipped.
The text was updated successfully, but these errors were encountered: