[sqlalchemy] Re: Column defaults in MapperExtension.after_insert
Michael Bayer wrote: > On Dec 11, 2007, at 10:07 AM, King Simon-NFHD78 wrote: > > > > > I assume the problem is that my date_created column isn't > immediately > > available at the 'after_insert' stage, because it is > generated in the > > SQL INSERT statement, but hasn't been read back from the > database yet. > > Is there a more suitable hook-point than after_insert, where I can > > safely read values like this? > > > > this is a thorny issue, while the immediate issue youre having is > something that can possibly be smoothed over (probably even by > sticking on the _instance_key yourself, not sure if i should > recommend > that though), its not going to work if say you wanted to look at the > foriegn key attributes in an attached collection since they havent > been set up yet. > > also the API youre using with get_history() has changed in > trunk, itll > give you a tuple now of (added, unchanged, deleted). > > there is the notion of SessionExtension which has an after_commit() > hook, not sure if that is a viable option here. I cant go too nuts > with all these extension hooks since they all add latency to > everything (sorta wishing there were a lot less hooks as it is). > Thanks - I've ignored your warning and stuck on the _instance_key, in the full knowledge that when it breaks it'll be my own silly fault ;-) I'll investigate the SessionExtension as a longer-term fix. If after_commit runs when all attributes are completely up-to-date, and I can still access the previous and new state via get_history, it sounds like the right thing to use. I fully understand your worries about hooks slowing SQLAlchemy down, but I also think that they are one of the features that makes the ORM so flexible, and it would be a great shame to lose them. I wonder if there could be a way of caching all the extension methods so that applying them would be as fast as possible. OK, I should have guessed. You've already done that - I see the ExtensionCarrier checks which methods have been overridden when each extension is added. Thanks for your help, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Column defaults in MapperExtension.after_insert
On Dec 11, 2007, at 10:07 AM, King Simon-NFHD78 wrote: > > I assume the problem is that my date_created column isn't immediately > available at the 'after_insert' stage, because it is generated in the > SQL INSERT statement, but hasn't been read back from the database yet. > Is there a more suitable hook-point than after_insert, where I can > safely read values like this? > this is a thorny issue, while the immediate issue youre having is something that can possibly be smoothed over (probably even by sticking on the _instance_key yourself, not sure if i should recommend that though), its not going to work if say you wanted to look at the foriegn key attributes in an attached collection since they havent been set up yet. also the API youre using with get_history() has changed in trunk, itll give you a tuple now of (added, unchanged, deleted). there is the notion of SessionExtension which has an after_commit() hook, not sure if that is a viable option here. I cant go too nuts with all these extension hooks since they all add latency to everything (sorta wishing there were a lot less hooks as it is). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Column defaults in MapperExtension.after_insert
> This works nicely for attributes that I set directly. However, it
> breaks when it comes across a column that is defined as:
>
> sa.Column('date_created', sa.DateTime,
> default=sa.func.current_timestamp(type=sa.DateTime))
>
> The attached script should show the problem. The traceback is:
>
> Traceback (most recent call last):
> File "satest.py", line 32, in after_insert
> print " %s = %r" % (prop.key, getattr(instance, prop.key))
> File
> "/home/warranty/python/development/lib/python2.5/site-packages/SQLA
>lchem y-0.4.1-py2.5.egg/sqlalchemy/orm/attributes.py", line 40, in
> __get__ return self.impl.get(obj._state)
> File
> "/home/warranty/python/development/lib/python2.5/site-packages/SQLA
>lchem y-0.4.1-py2.5.egg/sqlalchemy/orm/attributes.py", line 215, in
> get value = callable_()
> File
> "/home/warranty/python/development/lib/python2.5/site-packages/SQLA
>lchem y-0.4.1-py2.5.egg/sqlalchemy/orm/attributes.py", line 628, in
> __fire_trigger
> self.trigger(instance, [k for k in self.expired_attributes if k
> not in self.dict])
> File
> "/home/warranty/python/development/lib/python2.5/site-packages/SQLA
>lchem y-0.4.1-py2.5.egg/sqlalchemy/orm/session.py", line 1112, in
> load_attributes
> if
> object_session(instance).query(instance.__class__)._get(instance._i
>nstan ce_key, refresh_instance=instance,
> only_load_props=attribute_names) is None:
> AttributeError: 'User' object has no attribute '_instance_key'
>
> I assume the problem is that my date_created column isn't
> immediately available at the 'after_insert' stage, because it is
> generated in the SQL INSERT statement, but hasn't been read back
> from the database yet. Is there a more suitable hook-point than
> after_insert, where I can safely read values like this?
>
i was going to suggest u to do a session.expire( that_attribute) but
as i see from the traceback it is going after expired attrs and
failing there, so thats for Michael... eventualy the after_insert is
happening too early and the _instance_key etc SA-system stuff is not
set on the object yet.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
