Comment by justin_vanw
16 years ago
> I basically couldn't populate databases from a unit test, then run a controller, then check the results, since SQLAlchemy would lose the connection after the controller.
What you say makes no sense. SQLAlchemy just uses the usual adapter for whatever database you are using. What does "loses the connection" mean to you? SQLAlchemy, by default, uses a pool of connections. I suspect you tried it for an hour and gave up without really understanding what you were doing.
From memory, committing to the database involves both saving and closing the connection. So when you get back to the unit test, there's no database connection.
Maybe there's a way to do it properly within SQLAlchemy, but if so it's completely non-obvious from a few days of searching the web, Pylons documentation, Pylons book, mailing list, etc.. I wasn't trying to do anything fancy, just set up a very basic unit test.
Here's one of my old comments with some more detail: http://news.ycombinator.com/item?id=1176948 "Instance <Foo at 0x103779f90> is not bound to a Session" was the error that I was getting.
http://www.sqlalchemy.org/docs/session.html?highlight=expung...
The following is more of a screed than a personal response to your post, so please don't take it personally.
This is something I run into quite a bit more than you might expect. Partly it is because I used to spend a lot of time in #sqlalchemy, #pylons, #pocoo, #python, and #postgresql on freenode (I'm 'ltbarcly' on freenode, feel free to msg me HNers!). For some reason it is common to believe that you can sit down and write applications that use an ORM and relational database without knowing both the ORM and relational databases.
If you are going to use relational databases, you should be prepared to become an expert in SQL, Database drivers, unicode (and why utf-8 or any other encoding isn't the same as unicode, in the same way that jpg or gif isn't the same as image data), indexing, data types, normalization tradeoffs, transaction isolation levels, locking semantics, ACID tradeoffs, how to read and understand query planner output, and much more. This is a lot to know, but if it were a college class it would be less than a semester long.
If you are going to use an ORM you have to know everything you would need when you use a relational database, and in addition how and when the ORM performs queries, how it maps to the database, what queries it will produce and when for any given action or attribute access, how db transactions map into the orm operations, how to perform common SQL operations via the orm (rather than loading more data than you need and filtering or joining via the application).
I think what he might be referring to is when you run an in-memory SQLite database in your unit tests (which is common practice, for speed and convenience). If the test server runs in a separate thread to the unit test, then they use two separate in-memory databases and you cannot populate the server database from your unit test setUp.
This however does work in Django - presumably by somehow passing the same DB connection to the test server.