your s.close() is not being reached
I've checked and found that every thread closes connection. And this
traceback :
QueuePool limit of size 5 overflow 10 reached, connection timed out
most probably caused by long running thread which walking over list of
filenames ~ 35 000 long. It renaming
oops, this part I've added accidentally:
from threading import Thread, Lock
from sqlalchemy import create_engine, MetaData, Table, Column, types,
...
In fact I've removed Lock's, remplaced scoped_session(...) with
create_session(bind=db) in each thread and was running app on 3912
revision.
2007-12-12 00:19:24,099 INFO sqlalchemy.pool.QueuePool.0x..90 Created
new connection connection object at 0xda9bd0; dsn: 'dbname=df
host=localhost user=grey password=', closed: 0
2007-12-12 00:19:24,099 INFO sqlalchemy.pool.QueuePool.0x..90
Connection connection object at 0xda9bd0; dsn:
Thanks a lot, seems I've managed resolve problem with concurrent
modifications by commit(), clear() and close() at each thread, but
stuck with another one:
Exception in thread Thread-62:
Traceback (most recent call last):
File threading.py, line 442, in __bootstrap
self.run()
File
i can only make comments about fragments like this but i cant address
your full design issue since you havent supplied a fully working
illustration of what it is youre trying to do.
the daemon: http://dpaste.com/hold/27089/
and required utils.py modele: http://dpaste.com/hold/27092/
it
I think the error throw of the IntegrityError is totally expensive
from both a DB perspective as well as a python perspective. if
missing data is truly so rare then it might be fine, but the
necessesity of then using SAVEPOINT seems to complicate things more
than necessary. but you'd have to
you should select() for the record first, and if not present, insert()
it. if youre concerned about lots of selects() you can implement a
simple cache in your application, such as a dictionary of ids that
already exist. if theres concern over the cache growing too large,
you can use a
one immediate flaw I see in your application is that you are using
implicit execution of SQL constructs without them having any
connection to the ongoing transaction, such as:
f_table.delete(f_table.c.user_id==theone.id).execute()
f_table.insert().execute(user_id=theone.id, path='/', ls=ls)
On 30 нояб, 21:07, Michael Bayer [EMAIL PROTECTED] wrote:
hey there -
this is line 179 right now:
if bind in conn_dict:
similar mismatches in the stacktrace are present for lines 505 and 509
(line 505 is a blank line now).
the full snip of code is:
if bind
based on your stacktrace, here's your bug, fixed in r3839:
cannot understand how this is working
from sqlalchemy import *
from sqlalchemy.orm import *
session = scoped_session(sessionmaker(transactional=True,
autoflush=False))
engine = create_engine('postgres://scott:[EMAIL
i think its impossible for you to be getting the same stacktrace that
you were, can you post what youre getting now please...
Exception in thread Thread-6:
Traceback (most recent call last):
File threading.py, line 442, in __bootstrap
self.run()
File ./camper.py, line 104, in run
I'm probably completely wrong about this, but in your example above, I
don't think the statement f_table.insert().execute() necessarily uses
the same connection as the ORM-level transaction and queries.
If I got it right, then, as far as I know, two transactions is
impossible in one
the 0.4 pattern for using scoped_session is:
session = scoped_session(sessionmaker(transactional=(True|False),
autoflush=(True|False)))
defined globaly:
session = scoped_session(sessionmaker(transactional=True,
autoflush=False))
result:
Exception in thread Thread-3:
Traceback (most recent
it seems like youre doing something else in there that youre not
supposed to (like accessing SessionTransaction perhaps ? dont use the
old 0.3 patterns anymore).
First heard about SessionTransaction. Also I've looked through changes
between 0.3 and 0.4 versions and made changes.
heres a
default isolation mode settings usually dont need any changes. we
dont have an official API for that yet, so you can apply it to all
connections using a custom connect() function sent to create_engine,
or you can try setting it individually as conn = session.connection();
I was thinking to change isolation level in fact.
But first, I don't know how to do this with sqlalchemy, second, with
default isolation level commits should work properly weather or not
something were inserted or updated during commit and third, I was
using nested transaction like this :
Does someone have an idea how to fix the problem that cause this
traceback :
Exception in thread Thread-5:
Traceback (most recent call last):
File threading.py, line 442, in __bootstrap
self.run()
File ./camper.py, line 138, in run
walk(session, theone, root)
File ./camper.py,
You must istantiate an istance of the obj to be deleted.
This is an Object Manager, so all operation is available on object.
or you can execute a plain string-sql direclty from engine
connection = engine.connect()
connection.execute(DELETE FROM a WHERE b = c)
or I can do this :
Good Day sqlalchemy.
I was searching, but didn't found a way to delete records from db not
executing selection first.
So, how to represent this SQL statement in slqalchemy ORM :
DELETE FROM a WHERE b = c ?
not it look like this :
stuff =
Could someone please explain the following behaviour:
from django.http import HttpResponseRedirect, Http404
from django.shortcuts import render_to_response
from df.tst import Path as ThePath
from sqlalchemy import *
from sqlalchemy.orm import *
metadata = MetaData()
u_table = Table('auth_user',
20 matches
Mail list logo
