On Tuesday, August 28, 2012 1:45:55 PM UTC-4, Michael Bayer wrote: > > > On Aug 28, 2012, at 1:15 PM, Owen Nelson wrote: > > > I was under the impression that the query property was implemented as > part of the scoped session (not the non-scoped variety) from reading the > docs. Is this not the case? If this isn't the case, I wonder if my issues > will just *go away* by switching the type of session I work with (while > running the test suite). > > OK, using the query property too, then yes this has a link to the scoped > session. It's roughly equivalent to this: > > class MyMappedClass(object): > @classmethod > def query(cls): > return scoped_session().query(cls) > > so it means, MyMappedClass.query()... is going to use your scoped session, > which is going to pull out the current Session() from the current > threading.local() in the current thread. > > > > > > > Regarding transferring state along tests, I'm not talking about > persisting changes from test to test. I'm really talking about making > changes in setUp (or in the test method itself) then having them reflected > within the context of the wsgi app (attached to my TestCase's self.app > prop). > > > > Given the implementation of scoped session, I'm willing to bet that > webtest runs the wsgi app in a separate thread, which might explain some of > this. > > I'm fairly certain it doesn't do that. I have some pretty involved > testing scenarios using webtest where I swap out different engines/sessions > as it nests/un-nests into the remote connections, etc. You stay in the > same thread. However, if your WSGI app has it's own session setup/teardown > going on, webtest hitting your WSGI app is going to trigger all of that, > which could be interfering with the enclosing session setup you have going > on. So you need to make sure that your WSGI app plays nicely with tests. > I will often use a big global variable like "TESTS_ENABLED=True" just so > that the WSGI app knows to tread lightly. >
We don't have any special session bootstrapping in the app itself. In fact, I'd hope that the session maker that I create during the test setup is the same exact object used inside the app itself. Perhaps there's a reload() at work here messing things up. > > > > I'm still not really sure why flushing and committing changes from my > test method wouldn't be reflected inside the wsgi app however. Regardless > of what session you're using in which thread - the session should still be > querying the database for the requested data, no? Furthermore, what reason > could there be for Session.close_all() making this all work (sort of)? > > mmm yeah I can't really say from this end. You'd need to get in there > and see exactly at which point sessions are being set up and torn down. > But I'm pretty sure you don't have any extra threads going on unless you > have something in your app that specifically spawns a thread. > It might not be webtest that's starting new threads, but rather the app engine nose plugin, or the various testbeds that come with (task queue emulation, search service, datastore, etc). For checking the setup/teardown of the sessions, what's the recommended tactic? I'm thinking: hook up some logging to some session events. > > > > > The issue I was seeing with sqlite :memory: was that after closing > sessions the schema would go away. Seems like to get this to work, I'd have > to make sure a session was kept alive throughout the run of the test (which > is what I want anyway). > > well this is also strange, because an engine that uses sqlite with a > :memory: connection will keep the connection persistent, using the > SingletonThreadPool. Closing the session won't affect this connection > being open assuming default usages. If your create_engine() is specifying > a specific pool like NullPool, then yes :memory: won't work with that. > > We specified a StaticPool -- I'll omit and see if that yields a better result. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/COUqErlZIpAJ. 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 options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
