On 3/26/07, Michael Bayer <[EMAIL PROTECTED]> wrote: > On Mar 26, 2007, at 6:15 AM, Gaetan de Menten wrote: > > though, as a user, I'd prefer the first solution. > > > > Wouldn't that be possible? I think it should be. You only need to keep > > the deferred approach of the InstrumentedList that I demonstrated in > > my patch, so that the whole list is not fetched before we get the > > query object, which would ruin the whole idea. Of course it was only a > > proof-of-concept patch, but I think it should be fixable. > > my various issues with the deferred thing are as follows. note that > im not putting these out there as "this is why we arent doing it", im > putting it out there as "this is why it makes me uncomfortable". > > the current use case of "has my lazy list been loaded?" is: > > "addresses" in myobject.__dict__
I didn't know about that subtlety... But is this really a common case? I can't think of any practical case (outside the internals of SQLAlchemy) where you'd want to do that. I guess I'm probably lacking imagination here :) > with deferred list, now we have to have a list element actually > present there (but still loaded, maybe not). so detecting when an > attribute requires its callable fired off or not gets thorny... > also > breaks code for those who do it the above way, but also we need to > add some new way to accomplish the above, True, but IMHO, it's worth it, since it breaks something which _I think_ is rarely used, to bring something which _I think_ would be used more widely once people know about it. The problem is that I might be wrong. > which will probably have to > be some messy function call like "attribute_manager.is_loaded > (myobject, "addresses")". How about an "is_loaded" method on the InstrumentedList itself? > generally theres all sorts of places where we want to get at the > attribute and fire it off, not fire it off (internally known as > "passive"), etc. and the awareness of the "deferred" list there would > have to be more deeply embedded throughout the attributes module for > everything to keep working. so my discomfort grows that we are > changing the APIs of attributes.py, probably including its public > API, just to suit something that IMHO is strictly for visual appeal. Well, I disagree here (I guess you expected that ;-))... It's both shorter to type and more readable that having to do the query manually each time. And btw, if you think like that, you could say that SQLAlchemy is only for visual appeal, since you could as well issue the SQL statements to your db cursors by hand. But let's not start a troll here. > also, while it looks cleaner, there is still a semantic co-mingling > that im not very comfortable with. i.e. that a collection of > persisted objects on a parent class doubles as a database query > object. to me the meaning of those two things is entirely different, I understand your point, and I agree that they are currently different concepts, but I have a deep feeling that they don't necessarily have to be. The collection is, after all, only a particular query which has been "concretized". I think it should be possible to get rid entirely of the "concretized" collection altogether, and only use queries. Ie: user.address is just an automatically-built query. It would feel very natural to me. Of course, in that case, we'd have to support tracking of objects added/removed/etc in a "query" (ie partial collection) like you do in the collection, but I don't think it would be _that_ hard. Ok, now the problem is that, even though I think it would be theorically feasible and super-cool to have, it would be a major refactor of the code breaking the API in some cases and you might not want to do that. BTW: this is what I meant in my first mail by "I _think_ the best way to go would be if InstrumentedList would hold a "preconfigured" query object"... Ok, now you call me crazy if you like. I'm currently having this "gut feeling" that this is the way to go, but maybe I'm missing something enormous because I don't see the whole picture like you do. > and i think the decline of an API starts with minor conflation of > concepts. That's so true. Now, if I failed to convince you, you might agree with a less invasive (but unfortunately also less beautifull/readable/practical) change like a function or method somewhere to create a query from an attribute: make_query(user, 'addresses') or make_query(User.addresses, user) or Query.from_attr(user, 'addresses') or anything similar... You get the idea... -- Gaëtan de Menten http://openhex.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
