sfmagic.org Rewrite: SQLAlchemy
This isn’t much of an update. Over the last two days I’ve been struggling with installing SQLAlchemy, a database wrapper/object-relational mapper for Python. It’s the default database interface layer in Pylons, and I had been anticipating easy setup and use for the simple side of the database transactions I want to do.
Things like reading from the tables without any joining or comparison, and writing basic data. This did not work out, and I had a lot of trouble with it. Much of this had to do with other problems, mostly installation/compiling problems, rather than SQLAlchemy in Pylons.
One bad problem I ran into and couldn’t fix was that the autoload parameter for the Table function simply didn’t work. I was following the Pylons guide, and it contains a line about swapping out its example for the autoload if the table already exists. I did this, and then assumed that there was some other setup problem in my project when it didn’t work. I couldn’t find the answer, and eventually installed the example project, changed that line as per the instructions (the table in question definitely existed in the database), and it still didn’t work.
So I’ve decided not to use that part of it for now, which isn’t too terrible as I was concerned about the performance of my queries using the ORM layer. Instead, I’ll use the SQL expression syntax, which I hope will still save me quite a bit of time.
I do have Pylons running, and the debugger (which I just love), and Genshi, and have a basic controller working. So hopefully over the next couple of days I’ll actually get to the point of reading from and writing to the database in a meaningful way.
21 Dec 2007 at 10:34
Speaking with no experience with ORM packages other than Java ones, you shouldn’t need to worry about performance problems with whatever ORM package you’re using. Any decent ORM will allow you to write custom SQL for performance critical cases, and free you from the ordinary drudgery.