Michael Bayer wrote: > you might want to temporarily disregard whatever theyre doing with > turbogears, since it seems theyre still using patterns that are only > relevant to the 0.1 series, particularly the AutoConnectEngine which > is totally obsolete, and it seems theres a level of conceptual > confusion going on there that needs to be worked out. the tutorial > page in the SA docs, as well as the "data mapping" section, > illustrate some pretty barebones examples of using the SA orm, > without using any threadlocal mods or sessioncontexts, since that > seems to be the source of most of the confusion. >
I was kind of hoping someone would say that. I'll try to avoid the built in SA stuff. > heres the most basic and explicit ORM pattern. you might want to > start with this as it has the least amount of anything going on. > this pattern is the one used on the "data mapping" documentation, > http://www.sqlalchemy.org/docs/datamapping.myt . > > # step 0. imports > from sqlalchemy import * > > # step 1. database metadata > metadata = MetaData() > table1 = Table('mytable', metadata, Column('somecol' ...)) > > # step 2. model > class MyClass(object): > .... > > mapper(MyClass, table1) > > # step 3. work with a session > > session = create_session(bind_to=someengine) > instance = MyClass() > session.save(instance) > session.flush() > I'm quite comfortable with that pattern. It makes sense to me and I like thinking in terms of "sessions". The problem for me is how/when to connect a session to an engine in a threaded environment (CherryPy). Since an engine manages a pool of connections, it wouldn't make much since to initiate an engine within a child thread. Then each thread would be calling create_engine and there would be a connection pool for each thread. Or is this a desired behavior? I thought defining the engine in the main thread and referencing it from other threads was good. O.K., I think I clearly communicated my confusion. > and thats it ! > > it seems from symptom 1 and symptom 2 that your objects are not > finding their way into Sessions, or are getting removed. if you > stick with the simpler pattern above, it should be clear what Session > your objects are a part of. symptom 2 also should be raising an > error instead of returning None/blank list; you should use the latest > trunk until i release 0.2.4 which fixes this issue. > > the other stuff youre doing relates to SessionContext objects, which > are an optional extension to SA, and that is probably where things > are going wrong. I would suggest not using SessionContext at first, > as its an extra layer of "automatic behavior" that isnt really needed > to get things done; it is most useful when you want to have a Session > automatically created in correspondence to a particular thread, and > you want new object instances to be automatically associated with > that Session. before doing anything more with > "sqlalchemy.ext.threadlocal" or "mapper.get_session()", make sure you > master the non-contextual pattern above first. when thats done, you > should read the plugins page at http://www.sqlalchemy.org/docs/ > plugins.myt which fully describes whats going on with the > "threadlocal" mod and SessionContext. The docs are great and I've looked over this section a few times trying to figure out how to operate with the threadlocal SessionContext. I keep going back over and over again trying to pick up some more each time. TG imports sqlalchemy.mods.threadlocal Doesn't this set the SessionContext to threadlocal application wide? How can I and should I deactivate it? Must I comment it out in the TG code? Thanks. Randall 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 Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users