On Oct 28, 2007, at 6:58 PM, Ron wrote:
> > Ok, I've figured out the problem but not really sure what the proper > solution is. > > Basically, I have Thing objects that can have attributes associated > with them. I have other classes that are subclasses of the Thing > object. These classes can provide more specific functionality based > on the type of Thing it is. Since Thing and it's subclasses all share > the same table, I need a way to get the correct class based on what > type of Thing it is. I do this by examining the Attributes associated > with a thing. The different subclasses of Thing match different > attributes. In 0.3 I did this by called an instance._setProperClass() > function in the populate_instance method of a MapperExtension. This > seems to make 0.4 angry. If I call the same _setProperClass() after I > get the object normally everything seems to work fine. > > I've attached a simplified version of what I do in my code to > illustrate the problem. > > > What I did was kind of a hack in 0.3 so I'm not that surprised that it > doesn't work in 0.4, but I'm not sure how else to achieve the > functionality I'm looking for. Is there a better way to allow for > sqlalchemy to return objects of different types based on the data they > happen to contain? OK, there was an original "intended" way for this to happen if via MapperExtension, youd do it in create_instance() - just return whatever type of object you want. however, from looking at the error youre getting, this is actually not going to fix the problem here. the class of object determines which mapper is used to populate its attributes. the "populate" step and the new-in-0.4 "post-populate" step are not communicating here because the official mapper for your instance changes midway (its based on class). while I can make the "post-populate" step ignore the mis-communication and just not fire off, or i can change how those two steps communicate, the fact remains that the *wrong* mapper populates your class (including in your 0.3 version)...so im not sure if its the right approach to support "wrongish" behavior like that. the "official" way to have the class and populating mapper selected based on attributes is using polymorphic inheritance. if your classes are all in an inheritance hierarchy, and theres a single attribute that can determine which is the right class, you can use that out of the box. it seems like your model could conform to that since its a single "type" attribute determining the class. I'd suggest trying to work with that model (single table inheritance). Otherwise ill probably have to add another MapperExtension hook to support this. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
