On Mar 27, 2007, at 2:08 AM, chris e wrote:
> > specific to the identity of the object. Is there currently a way, or a > plan to support, splitting the polymorphic query into two queries? The > first would get the base table, the second would retrieve the details > based on the discovered table. This way only two tables would be > queried instead of n where n is the number of polymorphic identities. what if you are querying for 10 objects that are of different polymorphic identities ? I do have some interest in expanding the mapper architecture to allow a single Query operation to result in multiple immediate select statements instead of one, this is how Hibernate usually does it in the default case. I hadnt yet noticed how hibernate does joined-table inheritance, if it is breaking up the table queries in the way that you mention. As yet I havent delved into how such an architecture could be added and it would be a very complicated refactoring. you can of course perform an operation like this manually - just query the primary table yourself, then issue the join against the two tables into instances(), or query against the specific subclass you've identified. if you have set up polymorphic loaders at every level, one useful thing on SA's side would be to allow a "polymorphic=False" option to Query to disable the polymorphic load. > Our DBAs have concerns that as our tables grow, possibly to the size > of 2.5million rows, that unioning against multiple tables, despite the > fact that we are unioning against a primary key, will become non- > performant. I know I could write a custom mapper to resolve this > issue, however, I thought I would bring this up since it may affect > other users, and there may already be a way to solve this easily of > which I am not aware. i think their concerns are valid, i wouldnt rely heavily on polymorphic loads for a high volume situation. but in the bigger sense, id be concerned about a complicated schema of joined table inheritances being able to scale very well in any case regardless of ORM (this goes to the slogan on SA's homepage...DBs act less and less like object collections the more performance starts to matter...). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
