no 'fetched' event when model or collection is loaded by eager loader

When collection is loaded in scope of parent ‘load’ or withRelated it receives only ‘fetching’ event. When model is loaded in that way it receives neither ‘fetching’ nor ‘fetched’.

Script:

Photo = db.Model.extend({
    tableName: 'photos',
    initialize: function() {
        this.on('all', function(event) {
            console.log("Photo :: " + event);
        };
    }
});

Photos = db.Collection.extend({
    model: Photo,
    initialize: function() {
        this.on('all', function(event) {
            console.log("Photos :: " + event);
        };
    }
});

User =  db.Model.extend({
    tableName: 'users',
    photos: function(){ return this.hasMany(Photo) },
    other_photos: function(){ return this.hasMany(Photos) }
});

new User(id: 1).fetch(withRelated: ['photos', 'other_photos']);

Output:

Photos :: fetching

[tgriesser]

Hey @bogus34 definitely appreciate the willingness to contribute, and the various tickets you’ve opened in the last few months (and bookshelf-fields plugin)… always helpful in getting input, hope it continues. I don’t know if “berated” was really the right term, feel like Ben was being a bit dramatic there… I think everyone could just take a step back and remember, it’s just javascript 😃

I personally wouldn’t have closed the ticket, so when I saw it was closed, I just didn’t feel like reopening another ticket that has been closed before I would have liked… so I just made a mental note about it.

I tend to agree with you that the model/relation life-cycles haven’t been fully thought out. I’ve been toying around with a big overhaul of relations which drops the entire “relations” and “eager” classes entirely and instead splits each relation into its own class. Each of these classes would have a well defined interface for the fetching / loading / pairing of models, so everything is really consistent. This should also be more efficient and give much better visibility into the relation state, provides a consistent way of defining new relation types. This would also be the suitable place to introduce events associated with eager loading. So on that front, and to ditch this ticket which has gotten quite derailed, I’ve opened #253.

@bendrucker I’d prefer if tickets in both projects are kept open unless clearly closable (I don’t even think I saw the #241 you referenced as to why it’s not supported). Again, this isn’t a personal inbox, it’s my repository… it’s pretty much been my focus for about the last year and while I am super appreciative of the willingness to help, the fact is that it’s not nearly at the state of being complete. Closing issues is easy, well thought out discussion on how to improve the underlying design is more difficult and what I’d prefer.

Also let’s do less “reprimanding” of people’s tone of voice in github tickets… sarcasm, language barriers and the like are not expressed well in tickets, and while it might be poor form to not be friendly regarding oss, it’s equally as bad to react poorly… don’t feed the trolls, so to speak.

[bendrucker]

Alexander,

It’s frustrating to be berated and disrespected for software we write and support for free. Please don’t do it again.

Unless Alice is on Github, please don’t speak in hypotheticals either. It’s not helpful to us, nor to you.

There are numerous closed tickets about the challenges of firing events on collection members and relations by default. I’d suggest reading them if you’re looking to better understand this issue. We are certainly not looking to spite you. There are good reasons for the decision to not have 100% event coverage everywhere you might expect them. I’m working on better documenting and explaining why.

If you’d like to share specific use cases and your full code, we can certainly help you find the best way to implement things.