Michael,
Thanks for the advice. I'm working with TurboGears and determined to
use SA, but having a tough time. TG defines a "PackageEngine" which is
a subclass of AutoConnectEngine. The SA imports look like this:
import sqlalchemy.mods.threadlocal
import sqlalchemy
from sqlalchemy.ext.proxy import AutoConnectEngine
My classes are not bound to a PackageEngine as illustrated in TG
examples. Instead, I import my classes, which use DynamicMetaData, and
add them to a session as needed. I define and engine so that it is
initialized with TG. I then reference that engine when I need a session
like
from tgwater import model
session = create_session(bind_to=model.engine)
so that I always reference the same engine. I'm guessing the sessions
are being opened in separate threads from model.engine. This is not
working out and I'm sure the answer lies in your response below, but I
can't seem to put it all together. Here are some symptoms.
Symptom 1.
I receive a persistent (I think) object and want to assign data to it.
I get the session and work on it like:
def save(self, project, **data):
session = sqlalchemy.object_mapper(project).get_session()
project.title = data['title']
session.flush()
But nothing is written to the database and I get no errors.
Symptom 2.
I query an object and pass it from the controller to the template.
Within the template, the lazy fields are None when they should contain
values. If I access them first in the controller, the values are there.
Strange, b/c I would think this is all happening in the same thread.
I don't mean to make this a TG thing. I'm hoping the symptoms will make
it obvious how I am misusing the SA connections. Thanks for the great
software and your help.
Randall
Michael Bayer wrote:
> connections are generally not held onto anywhere; so connection-using
> operations are usually threadsafe. the only time a connection is
> held onto somewhere is when you explicitly hold onto a Connection
> yourself, or a Transaction, or a SessionTransaction. A
> SessionTransaction occurs during a session.flush() as well, so
> Sessions are not connection-threadsafe when used with flush(). if
> you use a thread-local SessionContext, you should be fine in that
> regard.
>
> Also, objects loaded by a Session may have some lazy-loaders present
> on them which also can initiate connection-using operations, so that
> is something to be aware of. if you have objects with unexecuted
> lazy loaders that are going to be shared among threads, you might
> want to make sure they dont remain within a session that is going to
> be used for flush() operations.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
