On Mar 28, 2008, at 10:58 AM, Phillip J. Eby wrote:
>>
>> Sorry, I should have included more detail. You don't want to trigger
>> the logic in SA's __init__ decorator or call the user's __init__.
>> The
>> ORM policy is not to __init__ on load, and will soon support a
>> symmetric
>> "__on_load__" type of hook that the ORM can call post-__new__ when
>> reconstituting instances.
>
> So, which one of you is right? :)
Well, I'm not entirely sure how your users will be using their
objects. If they just want to take any old application and enable
trellis + sqlalchemy, if they are accustomed to writing for SA then it
would be a surprise for their __init__() method to be called. Like,
if I wrote a class like this:
class MyClass(object):
def __init__(self, a, b):
self.a = a
self.b = b
then I mapped it to Trellis + SQLA, we *can't* call MyClass() upon
load from the database - we dont have the constructor arguments
available and TypeError will be thrown.
If OTOH, using Trellis implies that you must already have an
__init__() that is compatible with a no-arg calling style and that
they should expect population of attributes to occur after it's
called, then theres no issue with configuring the SA mappings to call
__init__().
I think you mentioned earlier that Trellis "doesn't care" what the
user does with __init__()....neither does SQLAlchemy, and thats why we
never call it by default with no args, since we make no assumptions
about what it expects or what it does.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
