> not entirely true... we need to know those values in sqlalchemy - we > couldn't issue lazy loads
Not true at all. Maybe in the current implementation, but it isn't necessary whatsoever. Let's say you have class Thing, which is many to one to class Owner. If you want to lazyload relation "owner" later, all it would have to do is check if "owner" was present (or None) in the InstanceState. If that's the case, issue the SQL "If that's the case, issue the SQL "SELECT <owner attributes> FROM thing_table JOIN owner_table ON <literal join criterion, owner_table.id = thing_table.owner_id> WHERE <primary key relation to get thing_table>" and load the data into a new Owner object. I'm confused to why you need the actual key value for this? > properly issue flushes if we didnt keep > track of foreign key values (hm, maybe the flushes work). I don't know how your flush implementation works, but I doubt that's necessary either... > while we could try to "hide" all columns marked as "foreign key" somewhere, im > can assure you a very large portion of our userbase would be very > unhappy with that :). the behavior of a mapper is that it maps *all* > columns of a table to instance attributes by default, it doesnt try to > "guess" what columns you might be interested in. I think you misunderstand, I am not asking for another solution (I don't even want this particular solution either) when deferring key works fine. I don't want it to guess, no radical changes here. > blog post....blog post... :) Sorry! Was trying to lead into the next paragraph. On Nov 14, 11:29 am, Michael Bayer <[EMAIL PROTECTED]> wrote: > On Nov 14, 2007, at 11:07 AM, Chris M wrote: > > > > > It's quite simple actually, there is absolutely no need for 99% of my > > code to know these values after they have been set. I view the > > criterion of a SELECT as being the values I actually use in my > > application and the values of the key fields are only used inside the > > query itself to specify which tables get joined - they have no other > > use. I'll play devil's advocate here - why on earth would you need to > > load the values of these keys after they have been set? Do I use them > > in my application? No. Does SQLAlchemy actually _need_ for them to be > > loaded? Negative, it just has to generate SQL to the tune of > > "relation.id = table.relation_id" instead of "relation.id = %s" % > > table_instance.relation_id. > > not entirely true... we need to know those values in sqlalchemy - we > couldn't issue lazy loads or properly issue flushes if we didnt keep > track of foreign key values (hm, maybe the flushes work). while we > could try to "hide" all columns marked as "foreign key" somewhere, im > can assure you a very large portion of our userbase would be very > unhappy with that :). the behavior of a mapper is that it maps *all* > columns of a table to instance attributes by default, it doesnt try to > "guess" what columns you might be interested in. > > > > > It's simple enough to defer them in the mapping and save some data > > here and there for the massive resultsets I send to memcached (and > > load later), so why not take advantage of it? In the entire codebase > > for my (rather large) web site, there is only one location (which > > happens to be in the "peer edit version control system" that powers > > the news and articles) where I explicitly need the value of a key > > column. Regardless of the nature of my use, if deferred columns aren't > > to be allowed as keys in eagerload joins it should explicitly raise an > > error or the documentation should be supplemented with information > > about it :) > > theres no reason you shouldnt be able to do it. however the way im > fixing this, those columns are going to get undeferred by the eager > loader, so the foreign key attribute will be there when you do the > eager load. in fact im pretty certain that theyre going to get > uncondionally populated by flushes too. so a lot of things work > against your deferring of that attribute but I dont mind it if you > dont (well no, actualy i dont mind it :) ). > > its almost like youre looking for a "hidden column" feature here. > that could be interesting (but is probably not worth the extra > complexity). > > > > > I have done a lot of hacking of the SQLAlchemy internals (especially > > in 0.3.x, not so much 0.4.x) to better understand how it works because > > the.. erm... unique nature of my website requires complex demands out > > of the SQL generated by ORMs. Until 0.4.x, I couldn't even consider > > using SQLAlchemy's ORM so I hacked up a quick one for my own use. > > Since then, I have switched back to SQLAlchemy's ORM because I did not > > have the time to maintain my own solution in tandem with my website, > > my design/programming job, school, and other time constraints like my > > social life (as unnecessary it is!) > > blog post....blog post... :) yeah the 0.4 internals are pretty > revamped arent they. > > > > > Right now I'm working on Windows CHM generator for SQLAlchemy's > > documentation. I'd really like to contribute to this project in a > > meaningful way, it's the only ORM I have ever encountered that hasn't > > been completely inadequate for heavy duty production use in my > > opinion. Of course I could just write SQL by hand, but I really just > > don't have the time for that and it's hard to scale when I add new > > logic to the applications. If you have anything I could help with, I'd > > be glad to dedicate some of my limited time to hacking a bit! > > absolutely....browse around trac a bit and see if anything interests > you. i can get you commit access immediately if you have commits to > offer. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
