SQLObject Developer Guide

Contents

These are some notes on developing SQLObject. I'll try to expand them as things come up. If you are committing to the SQLObject repository, please also read /using-this-repository.txt, which is just about file layout and repository cooperation.

-- Ian Bicking

Style Guide

Generally you should follow the recommendations in PEP 8, the Python Style Guide. Some things to take particular note of:

Testing

Tests are important. Tests keep everything from falling apart. All new additions should have tests.

Right now all the tests are in one big file tests.py. Which is unfortunate, but that's the way it is. They may seem complex, but they aren't so bad really. They all subclass from SQLObjectTest.

The classes attribute is special in a test class. This is a list of SQLObject subclasses that this test uses. SQLObjectTest will create the tables before the tests are run, and destroy them after.

You may also define an .inserts() method. This method sets up the basic data. When doing verbose input (-vv) you won't see these inserts, since they may be overwhelming. Use the command-line options --inserts to show them (as well as the create statement.

When running tests, use -ddbname to test with dbname (e.g., -dmysql, -dpostgres, etc), or -dall to use Postgres, MySQL, Firebird, and SQLite (all the core supported databases; everything I have installed on my computer). Please try to test as many databases as you can. At least SQLite and one other should be easy, though if you can test both Postgres and MySQL that would be much better.

If you submit a patch or implement a feature without a test, I'll be forced to write the test. That's no fun for me, to just be writing tests. So please, write tests; everything at least needs to be exercised, even if the tests are absolutely complete.