Is there any way I can force a COMMIT within an exposed method ? I am using SqlAlchemy with PostgreSQL and I am creating a few records that I need to use for subsequent SELECTs within the same method. Although I do flush() them and get their assigned IDs, subsequent explicit SELECTs (using SA's select(), not the data mappers) fail to see the changes.
Alternatively, is there an easy way to turn off the transaction altogether for a specific method ? The workaround shown in [1] looks messy and error prone.
> Is there any way I can force a COMMIT within an exposed method ? I am > using SqlAlchemy with PostgreSQL and I am creating a few records that > I need to use for subsequent SELECTs within the same method. Although > I do flush() them and get their assigned IDs, subsequent explicit > SELECTs (using SA's select(), not the data mappers) fail to see the > changes.
How are you obtaining the engine when you use SA's select? You should use the same connection the transaction is using so you see its changes, check out [1]
> Alternatively, is there an easy way to turn off the transaction > altogether for a specific method ? The workaround shown in [1] looks > messy and error prone.
On Apr 16, 12:18 pm, Alberto Valverde <albe...@toscat.net> wrote:
> On Apr 16, 2007, at 5:54 PM, George Sakkis wrote:
> > Is there any way I can force a COMMIT within an exposed method ? I am > > using SqlAlchemy with PostgreSQL and I am creating a few records that > > I need to use for subsequent SELECTs within the same method. Although > > I do flush() them and get their assigned IDs, subsequent explicit > > SELECTs (using SA's select(), not the data mappers) fail to see the > > changes.
> How are you obtaining the engine when you use SA's select? You should > use the same connection the transaction is using so you see its > changes, check out [1]
I use:
from turbogears import database as db engine=db.get_engine()
How can I access the implicit transaction created by TG or its connection object ?
> On Apr 16, 12:18 pm, Alberto Valverde <albe...@toscat.net> wrote: >> On Apr 16, 2007, at 5:54 PM, George Sakkis wrote:
>>> Is there any way I can force a COMMIT within an exposed method ? >>> I am >>> using SqlAlchemy with PostgreSQL and I am creating a few records >>> that >>> I need to use for subsequent SELECTs within the same method. >>> Although >>> I do flush() them and get their assigned IDs, subsequent explicit >>> SELECTs (using SA's select(), not the data mappers) fail to see the >>> changes.
>> How are you obtaining the engine when you use SA's select? You should >> use the same connection the transaction is using so you see its >> changes, check out [1]
> I use:
> from turbogears import database as db > engine=db.get_engine()
> How can I access the implicit transaction created by TG or its > connection object ?
You'll need access to the transaction instance. Unfortunately it's a local variable inside database.sa_rwt. Perhaps it should be bound to cherrypy.request so you could do:
> On Apr 16, 2007, at 6:53 PM, George Sakkis wrote:
>> On Apr 16, 12:18 pm, Alberto Valverde <albe...@toscat.net> wrote: >>> On Apr 16, 2007, at 5:54 PM, George Sakkis wrote:
>>>> Is there any way I can force a COMMIT within an exposed method ? >>>> I am >>>> using SqlAlchemy with PostgreSQL and I am creating a few records >>>> that >>>> I need to use for subsequent SELECTs within the same method. >>>> Although >>>> I do flush() them and get their assigned IDs, subsequent explicit >>>> SELECTs (using SA's select(), not the data mappers) fail to see the >>>> changes. >>> How are you obtaining the engine when you use SA's select? You should >>> use the same connection the transaction is using so you see its >>> changes, check out [1] >> I use:
>> from turbogears import database as db >> engine=db.get_engine()
>> How can I access the implicit transaction created by TG or its >> connection object ?
> You'll need access to the transaction instance. Unfortunately it's a > local variable inside database.sa_rwt. Perhaps it should be bound to > cherrypy.request so you could do:
It would be nice if instead of holding onto a local reference to the transaction it used the one in the request object to commit and rollback (i.e. get rid of the transaction variable above and change all references to req.sa_transaction). I believe this would solve the problem where people want to be able to rollback the transaction and then start a new one within a controller.
> It would be nice if instead of holding onto a local reference to the > transaction it used the one in the request object to commit and > rollback > (i.e. get rid of the transaction variable above and change all > references to req.sa_transaction). I believe this would solve the > problem where people want to be able to rollback the transaction and > then start a new one within a controller.
Good point. Mind posting opening a tickjet at the Trac with a patch?
>> It would be nice if instead of holding onto a local reference to the >> transaction it used the one in the request object to commit and >> rollback >> (i.e. get rid of the transaction variable above and change all >> references to req.sa_transaction). I believe this would solve the >> problem where people want to be able to rollback the transaction and >> then start a new one within a controller.
> Good point. Mind posting opening a tickjet at the Trac with a patch?
>>> It would be nice if instead of holding onto a local reference to the >>> transaction it used the one in the request object to commit and >>> rollback >>> (i.e. get rid of the transaction variable above and change all >>> references to req.sa_transaction). I believe this would solve the >>> problem where people want to be able to rollback the transaction and >>> then start a new one within a controller.
>> Good point. Mind posting opening a tickjet at the Trac with a patch?
Alberto Valverde wrote: > You'll need access to the transaction instance. Unfortunately it's a > local variable inside database.sa_rwt. Perhaps it should be bound to > cherrypy.request so you could do:
