[sqlalchemy] Re: Extension Mapper

2008-08-30 Thread GustaV

It almost works.
A small problem though : when I get and modify instances (a priori not
loaded before the flush) in after_flush method, they are correctly
added in the dirty list of the session but the 2nd flush does nothing.
This is because the identity_map is still flagged as 'not modified'

On 29 août, 18:32, Michael Bayer [EMAIL PROTECTED] wrote:
 in r5069, extension can be a list of SessionExtension objects.  You
 can also append to session.extensions.

 On Aug 29, 2008, at 11:36 AM, GustaV wrote:



  You must be right.
  Of course, Turbogears2 already add an extension to the session, and it
  looks like it is not a list of extension anyway (or maybe in the
  latest trunk?).
  What the best way then? To subclass the tg2 extension with mine and
  continue to call overloaded method from mine? Anything better?

  On Aug 29, 3:57 am, Michael Bayer [EMAIL PROTECTED] wrote:
  On Aug 28, 2008, at 6:57 PM, GustaV wrote:

  Hi all.
  I'm currently working on a map (like in geography :) )

  When a new tile in inserted in the DB, I'm using an extension mapper
  to update some neighbor's properties (like the neighbors count). The
  after_insert method helps a lot... but:
  When I modify another object than the one being inserted in the
  after_insert method, the modification happens in the python object,
  but doesn't occur is the DB. The commit at the end does not seem to
  have an effect.

  What should I do?

  modifications to objects inside of flush() aren't going to propigate
  the same way as when they're outside of the flush().   Within
  MapperExtension you should generally just do things with the
  connection (i.e., issue SQL directly).

  Otherwise, we have SessionExtension which has a before_flush() hook,
  and you can poke around inside the Session and change things freely
  before anything flush()-related occurs.  The catch there is that
  you'd
  probably want to be using the latest 0.5 trunk for that (post beta3)
  since we've fixed it up a bit to work in a more useful way.   I find
  that using before_flush() and after_flush() is generally a better way
  to go for dependent changes/SQL to be issued since you aren't doing
  things inside of the flush() itself, where its hard to predict when
  things will actually happen.
--~--~-~--~~~---~--~~
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: Extension Mapper

2008-08-30 Thread Michael Bayer

use before_flush() for changes to the dirty list and suchor if  
you really want things set up for the *next* flush, use  
after_flush_postexec().


On Aug 30, 2008, at 10:08 AM, GustaV wrote:


 It almost works.
 A small problem though : when I get and modify instances (a priori not
 loaded before the flush) in after_flush method, they are correctly
 added in the dirty list of the session but the 2nd flush does nothing.
 This is because the identity_map is still flagged as 'not modified'

 On 29 août, 18:32, Michael Bayer [EMAIL PROTECTED] wrote:
 in r5069, extension can be a list of SessionExtension objects.  You
 can also append to session.extensions.

 On Aug 29, 2008, at 11:36 AM, GustaV wrote:



 You must be right.
 Of course, Turbogears2 already add an extension to the session,  
 and it
 looks like it is not a list of extension anyway (or maybe in the
 latest trunk?).
 What the best way then? To subclass the tg2 extension with mine and
 continue to call overloaded method from mine? Anything better?

 On Aug 29, 3:57 am, Michael Bayer [EMAIL PROTECTED] wrote:
 On Aug 28, 2008, at 6:57 PM, GustaV wrote:

 Hi all.
 I'm currently working on a map (like in geography :) )

 When a new tile in inserted in the DB, I'm using an extension  
 mapper
 to update some neighbor's properties (like the neighbors count).  
 The
 after_insert method helps a lot... but:
 When I modify another object than the one being inserted in the
 after_insert method, the modification happens in the python  
 object,
 but doesn't occur is the DB. The commit at the end does not seem  
 to
 have an effect.

 What should I do?

 modifications to objects inside of flush() aren't going to  
 propigate
 the same way as when they're outside of the flush().   Within
 MapperExtension you should generally just do things with the
 connection (i.e., issue SQL directly).

 Otherwise, we have SessionExtension which has a before_flush()  
 hook,
 and you can poke around inside the Session and change things freely
 before anything flush()-related occurs.  The catch there is that
 you'd
 probably want to be using the latest 0.5 trunk for that (post  
 beta3)
 since we've fixed it up a bit to work in a more useful way.   I  
 find
 that using before_flush() and after_flush() is generally a better  
 way
 to go for dependent changes/SQL to be issued since you aren't doing
 things inside of the flush() itself, where its hard to predict when
 things will actually happen.
 


--~--~-~--~~~---~--~~
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: Extension Mapper

2008-08-30 Thread GustaV

I planned to do it on the next flush as you said, but since it is not
very clean, I manage to do it in the before_flush method.

So, last message on that subject I think:
Since 'dirty' var is set before the call of 'before_flush' ( dirty =
self._dirty_states ); it doesn't take modification that occurs in
there into account. Maybe it should be re-set just after the call,
like the new and deleted variables.

Thanks a lot for your help! :)

Gus


On 30 août, 16:47, Michael Bayer [EMAIL PROTECTED] wrote:
 use before_flush() for changes to the dirty list and suchor if
 you really want things set up for the *next* flush, use
 after_flush_postexec().

 On Aug 30, 2008, at 10:08 AM, GustaV wrote:



  It almost works.
  A small problem though : when I get and modify instances (a priori not
  loaded before the flush) in after_flush method, they are correctly
  added in the dirty list of the session but the 2nd flush does nothing.
  This is because the identity_map is still flagged as 'not modified'

  On 29 août, 18:32, Michael Bayer [EMAIL PROTECTED] wrote:
  in r5069, extension can be a list of SessionExtension objects.  You
  can also append to session.extensions.

  On Aug 29, 2008, at 11:36 AM, GustaV wrote:

  You must be right.
  Of course, Turbogears2 already add an extension to the session,
  and it
  looks like it is not a list of extension anyway (or maybe in the
  latest trunk?).
  What the best way then? To subclass the tg2 extension with mine and
  continue to call overloaded method from mine? Anything better?

  On Aug 29, 3:57 am, Michael Bayer [EMAIL PROTECTED] wrote:
  On Aug 28, 2008, at 6:57 PM, GustaV wrote:

  Hi all.
  I'm currently working on a map (like in geography :) )

  When a new tile in inserted in the DB, I'm using an extension
  mapper
  to update some neighbor's properties (like the neighbors count).
  The
  after_insert method helps a lot... but:
  When I modify another object than the one being inserted in the
  after_insert method, the modification happens in the python
  object,
  but doesn't occur is the DB. The commit at the end does not seem
  to
  have an effect.

  What should I do?

  modifications to objects inside of flush() aren't going to
  propigate
  the same way as when they're outside of the flush().   Within
  MapperExtension you should generally just do things with the
  connection (i.e., issue SQL directly).

  Otherwise, we have SessionExtension which has a before_flush()
  hook,
  and you can poke around inside the Session and change things freely
  before anything flush()-related occurs.  The catch there is that
  you'd
  probably want to be using the latest 0.5 trunk for that (post
  beta3)
  since we've fixed it up a bit to work in a more useful way.   I
  find
  that using before_flush() and after_flush() is generally a better
  way
  to go for dependent changes/SQL to be issued since you aren't doing
  things inside of the flush() itself, where its hard to predict when
  things will actually happen.
--~--~-~--~~~---~--~~
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: Extension Mapper

2008-08-30 Thread Michael Bayer


On Aug 30, 2008, at 1:55 PM, GustaV wrote:


 I planned to do it on the next flush as you said, but since it is not
 very clean, I manage to do it in the before_flush method.

 So, last message on that subject I think:
 Since 'dirty' var is set before the call of 'before_flush' ( dirty =
 self._dirty_states ); it doesn't take modification that occurs in
 there into account. Maybe it should be re-set just after the call,
 like the new and deleted variables.

 Thanks a lot for your help! :)

good point.  thats in r5070.


--~--~-~--~~~---~--~~
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: Extension Mapper

2008-08-29 Thread GustaV


You must be right.
Of course, Turbogears2 already add an extension to the session, and it
looks like it is not a list of extension anyway (or maybe in the
latest trunk?).
What the best way then? To subclass the tg2 extension with mine and
continue to call overloaded method from mine? Anything better?

On Aug 29, 3:57 am, Michael Bayer [EMAIL PROTECTED] wrote:
 On Aug 28, 2008, at 6:57 PM, GustaV wrote:



  Hi all.
  I'm currently working on a map (like in geography :) )

  When a new tile in inserted in the DB, I'm using an extension mapper
  to update some neighbor's properties (like the neighbors count). The
  after_insert method helps a lot... but:
  When I modify another object than the one being inserted in the
  after_insert method, the modification happens in the python object,
  but doesn't occur is the DB. The commit at the end does not seem to
  have an effect.

  What should I do?

 modifications to objects inside of flush() aren't going to propigate  
 the same way as when they're outside of the flush().   Within  
 MapperExtension you should generally just do things with the  
 connection (i.e., issue SQL directly).

 Otherwise, we have SessionExtension which has a before_flush() hook,  
 and you can poke around inside the Session and change things freely  
 before anything flush()-related occurs.  The catch there is that you'd  
 probably want to be using the latest 0.5 trunk for that (post beta3)  
 since we've fixed it up a bit to work in a more useful way.   I find  
 that using before_flush() and after_flush() is generally a better way  
 to go for dependent changes/SQL to be issued since you aren't doing  
 things inside of the flush() itself, where its hard to predict when  
 things will actually happen.
--~--~-~--~~~---~--~~
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: Extension Mapper

2008-08-29 Thread Michael Bayer


On Aug 29, 2008, at 11:36 AM, GustaV wrote:



 You must be right.
 Of course, Turbogears2 already add an extension to the session, and it
 looks like it is not a list of extension anyway (or maybe in the
 latest trunk?).
 What the best way then? To subclass the tg2 extension with mine and
 continue to call overloaded method from mine? Anything better?

since I'm plugging SessionExtension quite a bit I'll look into turning  
that collection into a list.   For now you can try monkeypatching or  
subclassing TG's extension.


--~--~-~--~~~---~--~~
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: Extension Mapper

2008-08-29 Thread Michael Bayer

in r5069, extension can be a list of SessionExtension objects.  You  
can also append to session.extensions.



On Aug 29, 2008, at 11:36 AM, GustaV wrote:



 You must be right.
 Of course, Turbogears2 already add an extension to the session, and it
 looks like it is not a list of extension anyway (or maybe in the
 latest trunk?).
 What the best way then? To subclass the tg2 extension with mine and
 continue to call overloaded method from mine? Anything better?

 On Aug 29, 3:57 am, Michael Bayer [EMAIL PROTECTED] wrote:
 On Aug 28, 2008, at 6:57 PM, GustaV wrote:



 Hi all.
 I'm currently working on a map (like in geography :) )

 When a new tile in inserted in the DB, I'm using an extension mapper
 to update some neighbor's properties (like the neighbors count). The
 after_insert method helps a lot... but:
 When I modify another object than the one being inserted in the
 after_insert method, the modification happens in the python object,
 but doesn't occur is the DB. The commit at the end does not seem to
 have an effect.

 What should I do?

 modifications to objects inside of flush() aren't going to propigate
 the same way as when they're outside of the flush().   Within
 MapperExtension you should generally just do things with the
 connection (i.e., issue SQL directly).

 Otherwise, we have SessionExtension which has a before_flush() hook,
 and you can poke around inside the Session and change things freely
 before anything flush()-related occurs.  The catch there is that  
 you'd
 probably want to be using the latest 0.5 trunk for that (post beta3)
 since we've fixed it up a bit to work in a more useful way.   I find
 that using before_flush() and after_flush() is generally a better way
 to go for dependent changes/SQL to be issued since you aren't doing
 things inside of the flush() itself, where its hard to predict when
 things will actually happen.
 


--~--~-~--~~~---~--~~
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: Extension Mapper

2008-08-28 Thread Michael Bayer


On Aug 28, 2008, at 6:57 PM, GustaV wrote:


 Hi all.
 I'm currently working on a map (like in geography :) )

 When a new tile in inserted in the DB, I'm using an extension mapper
 to update some neighbor's properties (like the neighbors count). The
 after_insert method helps a lot... but:
 When I modify another object than the one being inserted in the
 after_insert method, the modification happens in the python object,
 but doesn't occur is the DB. The commit at the end does not seem to
 have an effect.

 What should I do?

modifications to objects inside of flush() aren't going to propigate  
the same way as when they're outside of the flush().   Within  
MapperExtension you should generally just do things with the  
connection (i.e., issue SQL directly).

Otherwise, we have SessionExtension which has a before_flush() hook,  
and you can poke around inside the Session and change things freely  
before anything flush()-related occurs.  The catch there is that you'd  
probably want to be using the latest 0.5 trunk for that (post beta3)  
since we've fixed it up a bit to work in a more useful way.   I find  
that using before_flush() and after_flush() is generally a better way  
to go for dependent changes/SQL to be issued since you aren't doing  
things inside of the flush() itself, where its hard to predict when  
things will actually happen.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---