On Mar 2, 6:50 am, Michael Bayer mike...@zzzcomputing.com wrote:
WRT your 5 insert example, what's wrong w/ explicitly marking those
single logical units inside a BEGIN ... COMMIT while running
autocommit ?
If they are truly unrelated things, then yes there's nothing logically wrong
with
On Mar 1, 2:29 am, Michael Bayer mike...@zzzcomputing.com wrote:
On Mar 1, 2011, at 1:42 AM, Romy wrote:
Getting some conflicting advice on autocommit and wrapping the request
in a try/except block on the Tornado mailing list, was wondering what
your thoughts are on the issues brought up
Getting some conflicting advice on autocommit and wrapping the request
in a try/except block on the Tornado mailing list, was wondering what
your thoughts are on the issues brought up in the following message
and its replies:
http://groups.google.com/group/python-tornado/msg/d06a7e244fc9fe29
--
everywhere.
If your app already has exceptions raised and keeps on going, then its a
given that you already have a try/except block somewhere in your
application doing that.
On Feb 25, 2011, at 6:49 AM, Romy wrote:
Hey Michael,
Just had a MySQL has gone away that I intentionally
On Feb 26, 1:20 am, Chris Withers ch...@simplistix.co.uk wrote:
On 26/02/2011 09:09, Romy wrote:
It sounds like a better approach would be to wrap each request
handler's code as follows:
try:
RequestHandler()
elixir.session.commit()
except:
elixir.session.rollback
Hey Michael,
Just had a MySQL has gone away that I intentionally triggered by
setting the pool recycle to be higher than wait_timeout. Afterwards, I
watched the commit() at the end of the request throw a Can't
reconnect until invalid transaction is rolled back, which the catch
block was handling
' state inadvertently. Watching your SQL logs could help
you to determine if things are happening that are undesirable.
On Feb 21, 2011, at 3:38 AM, Romy wrote:
Switched to autocommit=False, and calling commit(), followed by
remove() on every end-of-request, regardless of whether
Switched to autocommit=False, and calling commit(), followed by
remove() on every end-of-request, regardless of whether there's data
to commit or not.
Am I adding any unnecessary overhead ? And if so, how should I be
checking for dirtyness prior to committing ?
R
--
You received this message
Thanks Michael.
On Fri, Feb 11, 2011 at 1:44 PM, Michael Bayer mike...@zzzcomputing.comwrote:
On Feb 11, 2011, at 3:05 PM, Romy wrote:
On Feb 11, 9:13 am, Michael Bayer mike...@zzzcomputing.com wrote:
autocommit=True means every SELECT statement as well as every flush()
uses its own
, COMMIT log output. When I
introduce another query before the commit, the COMMIT is never
printed.
On Feb 10, 9:14 am, Michael Bayer mike...@zzzcomputing.com wrote:
On Feb 10, 2011, at 6:10 AM, Romy wrote:
I am testing autocommit=False, and the output pattern is consistently
missing
Ah, very good to know, thank you.
Does this also mean that, assuming a transactional engine like Inno,
while using autocommit=True, issuing a session.begin() does nothing
since a transaction's already in progress ?
On Feb 10, 12:27 pm, Michael Bayer mike...@zzzcomputing.com wrote:
DBAPI
On Feb 11, 9:10 am, Michael Bayer mike...@zzzcomputing.com wrote:
For instance, rearranging the below to:
user = User.query.filter_by(id=1).first()
user.x = user.x + 1
elixir.session.commit()
results in a BEGIN, SELECT, UPDATE, COMMIT log output. When I
introduce another query before
On Feb 11, 9:13 am, Michael Bayer mike...@zzzcomputing.com wrote:
autocommit=True means every SELECT statement as well as every flush() uses
its own transaction, that begins as the method is called, and is immediately
closed, within the scope of the method call on your end. begin() *only*
On Feb 11, 9:10 am, Michael Bayer mike...@zzzcomputing.com wrote:
that is absolutely true.
works in all of our tests do you have one to demonstrate ?
Thanks Michael, finally tracked this one down while creating tests
that weren't reproducing the issue.
It didn't dawn on me that the
I am testing autocommit=False, and the output pattern is consistently
missing a COMMIT. I don't quite understand what SQLAlchemy is doing in
its debug output, unless it's not printing everything that goes to
MySQL. Specifically, for code that looks like this:
user =
currently using MyISAM which has no transaction support, but
if I was using say InnoDB would there not be tangible downsides to
wrapping everything inside a transaction, including non-database CPU-
bound code ?
On Feb 7, 2011, at 7:46 AM, Romy wrote:
So I haven't really given too much
Got it.
My remaining question: if I stick with autocommit=False and eventually
use a transactional engine, how does wrapping the entire request
inside a transaction (say my request starts off with a DB query)
affect performance compared to using transactions inside only the
critical areas. Is
all the accounting into the try/except block so that the flush
completes fully before the autocommit expires everything. This is a change
to a pattern that's been the same way since 0.4 so hoping nothing bad happens
when we put 0.7 out into betas.
On Feb 7, 2011, at 2:52 PM, Romy Maxwell
So I haven't really given too much thought to the setup until recently.
Thus, some of this could well be silly.
Up until now it's been a global scopedsession per each Tornado process, with
autocommit=True, pool_recycle=14400, pool_size=20.
IIRC, the autocommit=True was a quick solution to the
Thanks Michael.
I think this has everything to do with the fact that I'm running
autocommit=True and the default expire_on_commit=True ! According to ticket
2041 http://www.sqlalchemy.org/trac/ticket/2041, all my flushes reload
objects !
Does this explain why, if I wrap the above code in my
Trying to figure out why my logs are showing a group of SELECT
statements after an update. I'm using Elixir on top of SQLA in the
following fashion:
squares =
Squares.query.filter_by(user=user_record).all()
for sq in squares:
sq.sxsw_status = value
elixir.session.flush()
return
Nothing else
, at 1:43 AM, Romy wrote:
Sorry Michael, 'self-contained' wasn't a proper term for that test
given that it required an initial DB state containing a single row.
I've modified your version to try and reproduce the bug.
Since yours didn't use elixir at all and I'm not familiar
look at them before writing to the list,
and it still didn't dawn on me.
On Jan 10, 1:19 pm, Michael Bayer mike...@zzzcomputing.com wrote:
yah MySQL doesn't really operate with a mixture.
On Jan 10, 2011, at 4:13 PM, Romy wrote:
Face palm.. missed the forest for the trees.
Does
.
On Jan 9, 2011, at 1:45 AM, Romy wrote:
I believe it's both mapped and present in the session -- the log
output seems to confirm it:
[I 110108 22:40:30 base:1075] BEGIN
[I 110108 22:40:30 base:1390] UPDATE invite_codes SET used=%s WHERE
invite_codes.id = %s
[I 110108 22:40:30 base
Sorry Michael, 'self-contained' wasn't a proper term for that test
given that it required an initial DB state containing a single row.
I've modified your version to try and reproduce the bug.
Since yours didn't use elixir at all and I'm not familiar with
elixir's internals, I was able to
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
26 matches
Mail list logo
