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.
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 :) 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!) 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! On Nov 14, 9:42 am, Michael Bayer <[EMAIL PROTECTED]> wrote: > On Nov 13, 2007, at 9:17 PM, Chris M wrote: > > > > > I didn't see any tickets about this on the trac, so I thought I'd > > bring it to everyones attention. Since it's a development version I > > wasn't sure if this mattered (or was known about), so if it does I can > > draft up a quick test case. > > thanks for the test case, im looking into it today. one question. > why on earth would you need to defer a column that is just a simple > foreign key to another table ? "deferred" was intended for things > like large text fields and such which are expensive to fetch. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
