On Mar 28, 2008, at 12:28 PM, Michael Bayer wrote:
> > > On Mar 28, 2008, at 12:13 PM, Phillip J. Eby wrote: > >> >> So you're still disagreeing with Jason, who's quite explicitly saying >> that SA's __init__ will blow up if it gets called. Which of you is >> right? :) > > SA's __init__ does not blow up if it gets called. It just checks that > mappers are compiled and sets up InstanceState if not already > present. I'm not sure if recent changes on the branch have changed > this, though I doubt it, since we have a lot of users that do > implement MapperExtension.create_instance() to call their __init__() > method. > I think I should summarize what is known about this: 1. being able to configure the ORM to call __init__() instead of __new__() has always been a supported use case. 2. there are general issues when you have an ORM or any other instrumentation layer call __init__(), which is that people like to define argument signatures and behaviors for their __init__() which may conflict with just being able to call it in a plain vanilla style. So you may not actually want to call __init__() across the board. 3. Our long-existing hook to change how an object is created is MapperExtension.create_instance(), which just expects an instance back, no opinion on how it's created. That isn't going anywhere. 4. Jason is working on new hooks in the branch that would be an alternative to using create_instance(). The new_instance hook specifically would *not* be where you'd just call __init__() from. But the management interface will allow you to define exactly how __init__ is decorated on mapped classes, including marking it with the "reconsitute" hook which means it would be called after new_instance is called. So an immediate workaround would be to play with MapperExtension.create_instance(), but our plan is that before the branch is merged, we will have more hooks at the instrumentation layer as well. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
