Thanks Kevin, I am writing my code that way. I do believe that when my database is populated that I will hit performance problems that will require that I bypass SQLObject or use it in a way that is less portable.
>From what I have been reading on the SQLobject mail list, SQLObject does not support database level referential integrity like triggers well. It does not support stored procedures since that is not cross platform. It is only realistic from a product like SQLObject to support the lowest common denominator since you don't want to be implementing Oracle features in python so SQLite can have triggers. There are a whole class of applications where you need the higher end features that could not be implemented in SQLite. You either have to sacrifice portability or performance. If you sacrifice portability, you should at least get really good performance which I am not sure that SQLObject will allow. By isolating my SQLObject code, I can look at that problem when I come to it without rewriting my entire application. For some applications, I expect to have to completely bypass SQLObject. I read somewhere that SQLAlchemy was thinking about writing a SQLObject wrapper. That might solve the problems. Alvin
