17 messages in com.googlegroups.sqlalchemy[sqlalchemy] Re: Use of new_instance(...
FromSent OnAttachments
Phillip J. Eby27 Mar 2008 11:51 
jason kirtland27 Mar 2008 12:01 
Michael Bayer27 Mar 2008 12:10 
Michael Bayer27 Mar 2008 12:42 
Phillip J. Eby27 Mar 2008 14:06 
jason kirtland27 Mar 2008 14:25 
Phillip J. Eby27 Mar 2008 17:38 
jason kirtland27 Mar 2008 18:08 
Phillip J. Eby27 Mar 2008 21:54 
Michael Bayer28 Mar 2008 06:44 
Phillip J. Eby28 Mar 2008 07:57 
Michael Bayer28 Mar 2008 08:37 
jason kirtland28 Mar 2008 08:55 
Phillip J. Eby28 Mar 2008 09:13 
jason kirtland28 Mar 2008 09:26 
Michael Bayer28 Mar 2008 09:28 
Michael Bayer28 Mar 2008 09:53 
Subject:[sqlalchemy] Re: Use of new_instance() in the user-defined-state branch?
From:Phillip J. Eby (pj@telecommunity.com)
Date:03/27/2008 02:06:29 PM
List:com.googlegroups.sqlalchemy

At 12:02 PM 3/27/2008 -0700, jason kirtland wrote:

Phillip J. Eby wrote:

I just noticed that in the latest version of the branch, there's a new_instance() call that is using a class' __new__ method in order to create a new instance, rather than using 'class()'. What I'd like to find out is how to get around this, because Trellis objects will not be properly initialized unless the 'class()' is called, with any initialization taking place inside __new__ and/or __init__. Trellis doesn't override __new__ or __init__, and doesn't care what they do. But the creation of an instance *must* be wrapped by the class' __call__ (i.e. class()), as there is a try/finally involved that must execute.

Any thoughts on how this might be refactored? What is

new_instance() used for?

new_instance creates an instance without invoking __init__. The ORM uses it to recreate instances when loading from the database. new_instance can be added to InstrumentationManager as an extension method... The ORM doesn't care how empty instances are manufactured so long as they can be created without initialization arguments, e.g. a no-arg constructor.

Does that mean that no attributes must be set from new_instance(), either?

On a separate note, I noticed that the class manager machinery allowed one to just directly subclass ClassManager instead of making an InstrumentationManager. Was that intentional? I preserved this behavior when I corrected the staticmethod failure problem, but the tests don't appear to test for that.