At 09:45 AM 3/28/2008 -0400, Michael Bayer wrote: >On Mar 28, 2008, at 12:55 AM, Phillip J. Eby wrote: > > Sadly, about the only way for me to implement that without code > > duplication will be to temporarily change the item's __class__ to a > > subclass with an empty __init__ method. Unless there's a way to > > change the generated __init__ method to take an extra flag or check a > > per-thread variable to skip the bits you don't want? What are the > > bits you don't want run, anyway? That is, what specifically mustn't > > happen? > >an end-user's __init__ method is not run when the object is loaded >from the DB since the ORM is going to populate its state explicitly. >its for similar reasons that pickle.loads() doesn't call __init__. >Its a common use case that someone's class needs to be constructed >differently when it is newly created vs. when it is re-populated from >the DB. > >The usual method we have of modifying this behavior is to use a >MapperExtension where you implement create_instance(). Then you can >build the object any way you want, using __init__, whatever. Why is >that not an option here ? ( or has it just not been mentioned ?)
Because Jason said this: At 06:08 PM 3/27/2008 -0700, jason kirtland wrote: >Phillip J. Eby wrote: > > At 02:26 PM 3/27/2008 -0700, jason kirtland wrote: > >>>> 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? > >> You should be able to set whatever you like there. > > > > So... new_instance() could literally just be a call to > > 'self.class_()', with no other behavior, as long as the constructor > > requires no arguments? The modified __init__ that SA inserts won't > > be a problem there? > >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? :) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
