request lifecycle
- https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/router.html
the commit on session_2 is happening in the tween_egress, but the rendering
is happening in the view_pipeline above it.
i think the only way you can accomplish easily is without using the
transaction manger
Beautiful. Skipping the psycopg2 initialization prevents that rollback and
allows SQLAlchemy to use the same transaction.
FWIW, I don't think pool_reset_on_return=None is needed, at least for my
purposes.
Thanks for the help and thanks for the advice about raw_connection(). I'll
get
gt;> > I'm writing some automated tests for some legacy python code using a
>> > psycopg2 connection. I'd like to check data in the database by using
>> > SQLAlchemy. I rollback the database transaction after each test in
>> > tearDown().
>> >
>>
connection. I'd like to check data in the database by using
> > SQLAlchemy. I rollback the database transaction after each test in
> > tearDown().
> >
> > The problem is my SQLAlchemy connection doesn't see the database
> updates.
> > At first I thought
On Tue, Aug 28, 2018 at 11:32 AM, 'Brian DeRocher' via sqlalchemy
wrote:
> Hey all,
>
> I'm writing some automated tests for some legacy python code using a
> psycopg2 connection. I'd like to check data in the database by using
> SQLAlchemy. I rollback the database transaction
to check data in the database by using
> > SQLAlchemy. I rollback the database transaction after each test in
> > tearDown().
> >
> > The problem is my SQLAlchemy connection doesn't see the database updates.
> > At first I thought they weren't using the same
On Tue, Aug 28, 2018 at 4:32 PM 'Brian DeRocher' via sqlalchemy
wrote:
>
> Hey all,
>
> I'm writing some automated tests for some legacy python code using a psycopg2
> connection. I'd like to check data in the database by using SQLAlchemy. I
> rollback the database transacti
Hey all,
I'm writing some automated tests for some legacy python code using a
psycopg2 connection. I'd like to check data in the database by using
SQLAlchemy. I rollback the database transaction after each test in
tearDown().
The problem is my SQLAlchemy connection doesn't see the database
Just to add to Michael's reply -- keep in mind that how you handle the
session (commit/rollback/close) will impact the state of any objects the
session loaded if you're using the ORM and that can have implications in
your app.
The default behavior of sessions is to have `expire_on_commit=True`
my stuff doesn't handle the transaction commit - that's purely
transaction / pyramid_tm
so i'll look into that code to see if its closing it. great lead,
thanks.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to
Hi Jonathan,
It's pyramid_tm -- it will clear the session on commit. It's
counter-intuitive (or at least it was for me) if you've spent a lot of time
with SQLAlchemy and using sessions directly, but you should try flush
instead of commit:
print userInstance.id
DBSession.flush()
that seems to be it...
when you commit, there is a call to _finish()
http://www.zodb.org/zodbbook/transactions.html#commit
_finish() is documented under abort()
http://www.zodb.org/zodbbook/transactions.html#abort
and it includes a session.close()
--
You received this message because
could anyone point in the right direction to either:
1. rebind an object to a new session
or
2. allow objects to still be 'read' in the detached state ?
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to
eric-
thanks. I'll post a followup on the pylons list.
i've already got a call to session.flush()
the problem is that i need the transaction itself committed in this
block. i have a series of database transactions that happen within
the request. the first database transaction should error
On Tue, Feb 14, 2012 at 7:19 PM, Jonathan Vanasco jonat...@findmeon.com wrote:
could anyone point in the right direction to either:
1. rebind an object to a new session
or
2. allow objects to still be 'read' in the detached state ?
Eric said it best: replace commit with DBSession.flush()
--
Jonathan,
You probably want transaction.savepoint() in that case. There's a pretty
extensive discussion here showing savepoints (and rollbacks to savepoints)
as a way of creating sub-transactions with pyramid_tm:
https://groups.google.com/d/msg/pylons-discuss/5Mj4R3YMXhI/GVFj2Du33JAJ
You can of
Hi,
http://dpaste.com/659618/
--
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
sqlalchemy+unsubscr...@googlegroups.com.
For more
Hello Michael
Thanks a lot for your quick response.
I changed this loop to:
or i in range(1000):
: sleep(15)
: print commiting
: mm.name=u'old name'
: s.commit()
: sleep(25)
: mm.name=u'new name'
: print commiting2
On Jun 2, 2011, at 11:35 AM, Aalok Sood wrote:
Hello Michael
Thanks a lot for your quick response.
I changed this loop to:
or i in range(1000):
: sleep(15)
: print commiting
: mm.name=u'old name'
: s.commit()
: sleep(25)
:
Yes its all so very clear now, kind of obvious :)
Thank you for taking out time to help me.
Regards
Aalok Sood.
On Jun 2, 9:20 pm, Michael Bayer mike...@zzzcomputing.com wrote:
On Jun 2, 2011, at 11:35 AM, Aalok Sood wrote:
Hello Michael
Thanks a lot for your quick response.
I
This may or may not be specific to SQLAlchemy (rather than elixir),
but I figured I'd ask seeing as how this list is much more active. I'm
experiencing only a partial rollback in the following code --
invite_code gets incremented even when the exception is caught and
session rolled back. When I
The rollback of attributes is actually an expiration of all mapped
attributes.So used would need to be a mapped column for its value to be
rolled back. Other than that, invite_code would need to be present in
elixir.session for that to work, if something is causing that not to be the
First, thanks for that quick answer, that explains it. I turned
autocommit on, and it works again.
That leads me to this question: I do have session.commit() sprinkled
throughout my code without any except: rollback() blocks, can that
lead to problems down the line? I had the impression that
On Sep 29, 2010, at 11:03 AM, tom wrote:
First, thanks for that quick answer, that explains it. I turned
autocommit on, and it works again.
That leads me to this question: I do have session.commit() sprinkled
throughout my code without any except: rollback() blocks, can that
lead to
Thank you very much, that was very helpful!
On Sep 29, 5:27 pm, Michael Bayer mike...@zzzcomputing.com wrote:
On Sep 29, 2010, at 11:03 AM, tom wrote:
First, thanks for that quick answer, that explains it. I turned
autocommit on, and it works again.
That leads me to this question: I do
Hello, I want to know if open a transaction inside another is safe and
encouraged?
I have a method:
def foo():
session.begin
try:
stuffs
except Exception, e:
session.rollback()
raise e
session.commit()
and a method that calls the first one,
thanks very much!
On 5月20日, 下午9时03分, Werner F. Bruhin werner.bru...@free.fr wrote:
Hi,
manman wrote:
yes,i known,but how do i do that? if not commit parent,how to get the
parent id?
flush should be enough, but I think you could also do:
assuming you have a relation parent
Instead of the first commit use flush. You have already committed so
you cant roll back.
so
session.begin()
try:
p=parent()
session.add(p)
session.flush()
c=child()
c.p_id=p.id
session.add(c)
session.commit()
except:
session.rollback()
On May 20, 11:31 am,
yes,i known,but how do i do that? if not commit parent,how to get the
parent id?
On 5月20日, 下午6时59分, kindly kin...@gmail.com wrote:
Instead of the first commit use flush. You have already committed so
you cant roll back.
so
session.begin()
try:
p=parent()
session.add(p)
Hi,
manman wrote:
yes,i known,but how do i do that? if not commit parent,how to get the
parent id?
flush should be enough, but I think you could also do:
assuming you have a relation parent
c.parent.append(p)
or the other way round
p.children.append(c)
Werner
Hello Michael,
Thank you for your replies. I've just tried to create a testcase but
proven to myself that it does raise an exception. I'll go back and
double check where I might be catching and passing on the exception.
Daniel
On Apr 29, 3:19 pm, Michael Bayer mike...@zzzcomputing.com wrote:
Daniel wrote:
I've learned a bit more. Apparently the sqlite database occasionally
gets locked by another process and that lock lasts longer than the
five second default timeout. SQL Alchemy quietly issues a ROLLBACK,
but doesn't say anything more about it. The result is that the
session
how is it that you know this is due to the SQLite timeout ? did you
create a test case ? creating a fully reproducible test case would be
the next step.
On Apr 29, 2009, at 5:15 PM, Daniel wrote:
I'm not catching it or re-raising it. Where else could I look to
solve this.
On Apr
squelching typically means one of two things.
either you're doing this:
try:
# do stuff with session
except:
print error !
# .. keep going
or, you are allowing concurrent access to a single session with
multiple threads, one of your threads is throwing an exception
(usually
Hi,
In an Exception catch block, one may or may not be sure if a
transaction object has had begin() called. Is it safe to blindly call
rollback() on a Transaction object, or is there a way to test if a
transaction is active before calling rollback() (or indeed commit!).
I couldn't find anything
Quick question I hope guys.
If I have an object which contains a bunch of children and cascade is set on
the relationships. When I add the parent object to the session and commit
it, are the children saved as part of a transaction by default? Or do I have
to do something special?
If I
I'm getting a ProgrammingError (I've pasted the last part of the
traceback at the bottom of the page).
The error comes from my first heavy-AJAX page in Pylons (postgres
backend). If I cause too many AJAX requests at a time, or even after
doing 3 non-overlapping AJAX requests, I get the error.
On Tuesday 20 March 2007 07:47:53 Benno Rice wrote:
Hi,
I'm wondering if it would be possible to have a situation where
transactions coming in from the ORM system could be sent to
multiple database servers at once.
If I were to look into adding this, where would be the best place
to
SessionTransaction will start transactions across any number of
databases, as different engines come into its querying scope. when
SessionTranasction commits, it commits all underlying transacitons.
so if you want to start all transactions at once, you can create a
new
On Mar 20, 2007, at 11:52 AM, Michael Bayer wrote:
however, this is not using two phase commit, which means that if one
commit fails, all previous commit's stay committed. if you want true
two phase commit I'd look into Zalchemy which has this feature.
actually i should correct myself -
Yeah, I think I explained badly.
What I was trying to show with the sqlalchemy vs postgres query logs
is that extra BEGIN that psycopg2 is sending before the SELECT that
sqlalchemy executes. The BEGIN is implicitly added by psycopg2 because
it's in its default transaction isolation state of read
On Feb 12, 10:30 am, JP [EMAIL PROTECTED] wrote:
But It would be nice to be able to have total control over the
transactional state of the connection, so that when I know that I'm
just doing a select or two I don't have to have the overhead of a
BEGIN that I know is useless, but as things
like the example illustrates, there is no
BEGIN being issued for every SELECT statement when using psycopg2 in
non-autocommit mode, which applies to SQLAlchemy as well. therefore
there is no performance bottleneck; this is a django issue only.
I guess we're reading the example differently.
im confused. the django thread seems to be saying that it is setting
psycopg2 *into* autocommit mode, which causes the problem; the default
setting of autocommit for DBAPI (and maintained in SA) is False. When
i wrote frameworks years ago I always thought autocommit mode was
the way to go but i
Jose Soares ha scritto:
Michael Bayer ha scritto:
not sure about that, i thought maybe the multiple flush()es are
breaking something but I just added a test case and it doesnt
reproduce. make sure youre on the most recent versions since that was
broken a few versions back...
then its likely a threading issue. not sure what your setup is but
you should make sure that the session is used in only a single
thread, typically via using a thread local variable (or using
SessionContext which provides this service).
On Jan 24, 2007, at 8:28 AM, Jose Soares wrote:
not sure about that, i thought maybe the multiple flush()es are
breaking something but I just added a test case and it doesnt
reproduce. make sure youre on the most recent versions since that was
broken a few versions back...
--~--~-~--~~~---~--~~
You received
Michael Bayer ha scritto:
if the transaction fails, the session goes right back to the same state
that existed before you called the flush(), as though nothing happened.
With this example:
trans = begin_transaction()
session = ctx.current
a = SomeObject(...)
session.save(a)
raise Exception()
48 matches
Mail list logo
