On 22/03/2007, at 6:04 AM, Michael Bayer wrote:
> > this is interesting, but what would prevent the same result by > creating different mappers for a single class using entity_name ? > thats the current way to persist multiple objects of the same class > in different ways. Hrm. I've reimplemented my code using entity_name and have some thoughts: The reason I like my approach is that it's more transparent. The entity_name approach requires sticking entity_name arguments all over the place which is somewhat annoying. However, my approach currently doesn't handle queries at all. I could hack around that by converting the query arguments into a fake object and handing that in but that seems unpleasant. What would be nice is a way to do this kind of farm-out in a way that didn't as much help from higher layers. I can provide the system with a function that will take an object key and return which engine, metadata or table object I want to use, I just need a way to glue it into SQLAlchemy without having to specify it every time I make a call to my Session object. Do you have any suggestions of how I might approach this? -- Benno Rice [EMAIL PROTECTED] http://jeamland.net/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
