> As for using the attribute as query, I agree with Mike that > attributes should maintain their special character, but I can see a > case for extracting a query from the attribute to do arbitrary > operations that don't impact the relation or the attribute itself. > Given that that session.query() is now generative, this seems like > a natural fit for the feature - turn an attribute into a query that > you can do with as you please, the attribute remains as-is.
maybe i don't get something here: if user.my_green_addresses maps to user....select( color=green), how would u prevent adding myredhouse to that collection? i.e. how would this keep your-data consistent? In this meaning, collection is not just a whatever query, it assumes some minimal validation part (A relates to B), and subcollections would have even more of that. Or all this would be read-only? if yes, why not just pack the whatever query() u need for that under some property/descriptor/decorator? That was my idea for using python-expressions - 1.convert the filter-expr into sqlalchemy clause + joins, 2. construct the Query() off that, 3. fire the query each time the whatever decorated attribute is used 4. and/or cache/reload it at certain conditions i've done this up to level 3; i just have no usage cases so far for level 4 yet (and whether that be a .query() or Query() or SelectResults not big difference imo.) > On 3/26/07, Gaetan de Menten <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
