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 one....i 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 -~----------~----~----~----~------~----~------~--~---
