[sqlalchemy] Re: Polymorphic collections / ticket #500
Yeah, disregard this, I found an easier way that doesn't fight SA. For the record, the use case is a polymorphic collection with the occasional exception. Exceptions were one-offs for which I didn't want to provide derived mappers because they were well, rare one-offs. Those exceptions were to be loaded with the base mapper as if it were the base class itself, but to have the different type differentiators for the app to recognize and use. The workaround is to simply add a sub-type column and do a second-level differentiation using that. Won't work if you can't refactor the db, but now that Mike has put the override flag in there, even that can be gotten around. On 3/7/07, Michael Bayer [EMAIL PROTECTED] wrote: im not sure if i understand the use case youre describing ? I also stuck the previously mentioned flag in the trunk, the exception message will tell you about it. On Mar 6, 2007, at 11:08 PM, Rick Morrison wrote: Mike: I think I've seen a few requests here on the list over the past months for some kind of default or unspecified or other catch-all for the occasional one-off exception to what are otherwise polymorphic collections. I think it's actually a fairly common use-case. I'll try some of Simon's suggestions (thanks), but I think real support for something like this would make sense -- could you think about the issue a bit? Thanks, Rick On 3/6/07, Michael Bayer [EMAIL PROTECTED] wrote: yeah, i didnt like adding this particular error message, but since it leads to a bigger problem later i sort of had to. i am sure a lot of people are going to hit this one. so i guess ill put a flag in for this onei think people shoud me made aware that they are allowing a potentially error-causing behavior to occur. On Mar 5, 2007, at 8:12 PM, Rick Morrison wrote: The fix for ticket #500 breaks a pattern I've been using. It's most likely an anti-pattern, but I don't see a way to get what I want in SA otherwise. I've got a series of entities class Person(): pass class Manager(Person): def __init__(self): # do manager stuff class Demigod(Person): def __init__(self): # do demigod stuff etc. there are mappers for each of these entities that inherit from Person(), so all of the normal Person() properties exist, but Person () itself is not polymorphic. That's on purpose, and because the class hierarchy of Manager(), etc, is not exhaustive, and I occasionally want to save instances of Person() directly. If I make the Person() class polymorphic on a column of say typ, then SA clears whatever typ I may have tried to set directly, and seems to make me specify an exhaustive list of sub-types. And so I leave Person() as non-polymorphic. I also have a collection of Person() objects on a different mapper, which can load entity objects of any type. Before rev #2382, I could put a Manager() in a Person() collection, and it would flush OK. Now it bitches that it wants a real polymorphic mapper. I don't want to use a polymorphic mapper, because I don't want to specify an exhaustive list of every class that I'm ever going to use. What to do? Thanks, Rick --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Polymorphic collections / ticket #500
im not sure if i understand the use case youre describing ? I also stuck the previously mentioned flag in the trunk, the exception message will tell you about it. On Mar 6, 2007, at 11:08 PM, Rick Morrison wrote: Mike: I think I've seen a few requests here on the list over the past months for some kind of default or unspecified or other catch- all for the occasional one-off exception to what are otherwise polymorphic collections. I think it's actually a fairly common use- case. I'll try some of Simon's suggestions (thanks), but I think real support for something like this would make sense -- could you think about the issue a bit? Thanks, Rick On 3/6/07, Michael Bayer [EMAIL PROTECTED] wrote: yeah, i didnt like adding this particular error message, but since it leads to a bigger problem later i sort of had to. i am sure a lot of people are going to hit this one. so i guess ill put a flag in for this onei think people shoud me made aware that they are allowing a potentially error-causing behavior to occur. On Mar 5, 2007, at 8:12 PM, Rick Morrison wrote: The fix for ticket #500 breaks a pattern I've been using. It's most likely an anti-pattern, but I don't see a way to get what I want in SA otherwise. I've got a series of entities class Person(): pass class Manager(Person): def __init__(self): # do manager stuff class Demigod(Person): def __init__(self): # do demigod stuff etc. there are mappers for each of these entities that inherit from Person(), so all of the normal Person() properties exist, but Person () itself is not polymorphic. That's on purpose, and because the class hierarchy of Manager(), etc, is not exhaustive, and I occasionally want to save instances of Person() directly. If I make the Person() class polymorphic on a column of say typ, then SA clears whatever typ I may have tried to set directly, and seems to make me specify an exhaustive list of sub-types. And so I leave Person() as non-polymorphic. I also have a collection of Person() objects on a different mapper, which can load entity objects of any type. Before rev #2382, I could put a Manager() in a Person() collection, and it would flush OK. Now it bitches that it wants a real polymorphic mapper. I don't want to use a polymorphic mapper, because I don't want to specify an exhaustive list of every class that I'm ever going to use. What to do? Thanks, Rick --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Polymorphic collections / ticket #500
I wanted to do something like this in the past, and in the end, rather than using polymorphic mappers it made more sense to create a MapperExtension which overrides create_instance. In create_instance you can examine your 'typ' column to decide what class to create, selecting one of your Manager/Demigod classes if necessary, or falling back to the Person class otherwise. Hope that helps, Simon From: sqlalchemy@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Rick Morrison Sent: 06 March 2007 01:12 To: sqlalchemy Subject: [sqlalchemy] Polymorphic collections / ticket #500 The fix for ticket #500 breaks a pattern I've been using. It's most likely an anti-pattern, but I don't see a way to get what I want in SA otherwise. I've got a series of entities class Person(): pass class Manager(Person): def __init__(self): # do manager stuff class Demigod(Person): def __init__(self): # do demigod stuff etc. there are mappers for each of these entities that inherit from Person(), so all of the normal Person() properties exist, but Person() itself is not polymorphic. That's on purpose, and because the class hierarchy of Manager(), etc, is not exhaustive, and I occasionally want to save instances of Person() directly. If I make the Person() class polymorphic on a column of say typ, then SA clears whatever typ I may have tried to set directly, and seems to make me specify an exhaustive list of sub-types. And so I leave Person() as non-polymorphic. I also have a collection of Person() objects on a different mapper, which can load entity objects of any type. Before rev #2382, I could put a Manager() in a Person() collection, and it would flush OK. Now it bitches that it wants a real polymorphic mapper. I don't want to use a polymorphic mapper, because I don't want to specify an exhaustive list of every class that I'm ever going to use. What to do? Thanks, Rick --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
