So, I'm having an issue and I'm not able to articulate it very well. This
unfortunately means I'm going to ramble, so please excuse me.
I have an application built on webapp2 (app engine) which up until a short
while ago used the google datastore (and their ndb ORM) as
its means of persistence.
Over the past couple moths we worked to re-wire the existing app using
sqlalchemy and google's "cloud sql" service. The application
porting process has gone fairly well, however our existing test suite has
become insanely fragile (which is making our lives pretty difficult).
Our tests are running against a vanilla mysql server, using nose, the gae
nose plugin, and webtest.
While I can't accurately describe the issue, or narrow in on exactly what's
going on, I can speak to the symptoms.
Generally, our test code will load in some initial data to work with.
Commonly, we'll use our ORM models to make adjustments to the inital data
from test to test.
After the adjustments have been made, we'll flush/commit then run some
assertions against the test app (using the webtest wsig scaffolding).
For many (but not all) of the tests, the work we do with the database is
not reflected during the calls to the app -- likewise the reverse is true
(we
can't use the ORM to assert that the app has made changes to the underlying
data).
The "cheap" fix we've found is to do a session.close() or
Session.close_all() at the boundaries (where we switch from TestCase scoped
model
operations, to the webtest app calls, or vice versa). This is actually
pretty terrible because it means we have to collect a bunch of scalar
values
prior to closing the session(s) with which to run queries with later, for
example:
# inside our testcase method ...
obj = Obj(name='foo')
self.sess.add(obj)
self.sess.commit()
id_ = obj.id
name = obj.name
self.sess.__class__.close_all() # if we don't ``close_all`` the
handler code doesn't know about the new row in the db
resp = self.app.get("/objects/%d/" % id_)
resp.mustcontain(name)
As I understand it these repeated closures will probably slow down our
suite speed (less important) but will also mean we will never be able to
hope to leverage
sqlite :memory: as cheap/quick backend for testing app logic (which would
be great to be able to do!)
It would also be nice to be able to get a model instance out of the
database, test values on it, make some requests to the app, expire said the
model instance's
props, then make some assertions about the values. Right now, we can't do
that because any instances we have in our test code will "go dead" once we
close the
sessions(s).
As a guess, I think this has to do with how scoped sessions work, but
exactly how they work is a bit of a mystery to me. Have you seen anything
like this behavior before?
I'm not quite sure how to investigate further into this issue, so any
pointers would be appreciated.
Regards,
Owen Nelson
--
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/-/Wb8H2OVQ4C0J.
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.
