As regards the "attribute" in MappedObject.__dict__, I for one use it on an object which has an attribute whose primary role is to keep a work history which can get large. Sometimes, if the list has already been loaded, it's easier to simply add a new row to the already-loaded history. Sometimes if the history is not loaded, it makes more sense to do a one-off insert (via session.save()) of the new item to avoid incurring an uneeded load of lots of rows.
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. 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 -~----------~----~----~----~------~----~------~--~---
