making apps, making webs.

About a year ago I had to implement a system where the table name could be configured for an application.  Why would you want to do that?  Lots of reasons really, like if you have a table generator via a web interface.  In this case, the system integrates with other systems, and users need a way to specify where the data would go in an existing database.  So I merrily went ahead to try and put the table name in a prepared statement... but ERROR!  Unfortunately the sqlite database does not do table names or column names via prepared statements (like postgresql does for example).  The documented solution by sqlite is to escape them correctly with the provided functions.  Unfortunately python does not expose these SQL escaping functions - since most people should be using prepared statements. Here are some WONTFIX, closed, invalid bugs also mentioning table names, and column names not being a problem.  One of them is six years old. (closed wontf...

If a python ORM you know of addresses these issues, please let me know. Python ORMs break with multiple processes. Multiple processes are not assumed. Python ORMs all seem to use heavy local caching, which fails when the database is modified by another process. This is unfortunate as for me I like to use different tools for different jobs. Or there might be different people I work with that write tools in different processes. Or even the common case that each web request is run in a different process - or on a different machine. It is not commonly known that just because something outside of a python app changes a database that the python app will break. Most applications that use databases do not break if the database changes from outside of the application. Using memcache or something like it seems to be a solution to some of this problem. Also optionally allowing the ORM to not cache certain queries - or even stopping all caching. Caching using python dicts is bad anyway, bec...

It looks like SQLObject has versioning now. "So, a version is a special attribute that catches updates and stores older values in a special additional table." This is a very useful thing that I've been using on some projects myself. With it you can more easily recover from errors, and it also can allow your users to search through changes. If SQL had versioning built in, it'd be much nicer. Temporal SQL is the name for this. However I think Oracle is the only major database to support it. No free ones do. So storing it in another table is an ok compromise. I'm looking forward to the next SQLObject release - with versioning support, and other goodies. Written by a Melbourne web developer . Available for your projects - php, mysql, e commerce, javascript, CMS, css, flash, actionscript, python, games, postgresql, xml.