On Wednesday 27 June 2007, Mike Orr wrote:

If it could, yes. Right now it looks to me like SA automatically rolls every select back without a way to tell it not to (and no, explicit transaction didn't do the trick, but then I'm not an expert on SA, so there may be a better way)

Interoperability has gotten better? A bit probably, but not all that much :-( On the other hand, if you're as likely to change your DB model as you are to modify your application, your app and db model are either very simple, or the db model wasn't designed all that well. My current application has 513 tables and been in production for about 5 years. The application running on top of it was changed numerous times, the DB model had only 3 changes (all minor, like adding a field to a table) over the years and the stored procedures/triggers/views actually never changed. In my case there are third party applications accessing the database (i.e. someone made fancy reports with Crystal Reports), so changing the DB structure is a major pain with a lot of paperwork where changing the application is not.

I'd also like to argue that everyone in the open-source field would certainly love to see companies adopt open source over proprietary software. One of the factors for that decision is whether the requirements for large scale deployments are fulfilled. I'd love to see Bank of America run their homebanking on something open-source, but I doubt they do - one of the reasons being that their requirements aren't met by a lot of frameworks out there.

Actually I'd also argue the "convenient" point. How is a ORM convenient? Having a query with say 20 joins leads to a "pythonic" but pretty much unreadable, much less comprehensible query definition. Everyone dealing with SQL databases should be able to read SQL, but a query object definition that doesn't even fit on 2 pages anymore is far from readable. So yes, there are reasons why one would use ORM's and there are some against ORM's - a split SA has actually mastered fairly well since you don't have to use the mapper part.

You'd still have to consider all the incompatibilities between databases. PostgreSQL has far more data types, some of which are not handled by SA (i.e. arrays, which again are not SQL standard but very useful). Also be aware that SA doesn't handle postgresql user types correctly (particularly with autodetect), so be prepared to patch SA when you use the geographical functions. In the end, the moment you NEED to switch databases because of features missing in the current one, you're already on the way to lock yourself into one database (i.e. what if you want to move your application to DB2? Does DB2 have geographical functions?).

In the end, whether you use features like views, procedures, triggers etc. or not, is just a question of whether it makes sense for the application. Since Pylons and TG are frameworks for pretty much any application, they just should support such features without having to patch core components.

Uwe