What’s new in this release? The most important changes are fixes to a number of issues identified by users of SQLPython. Gerald was appearing to take a long time to collect large schemas but was actually failing silently. I added test cases to show the problem and then fixed the code. This shouldn’t happen any more.

I applied a couple of patches supplied by Catherine Devlin to cope with columns without defined lengths and to not get DBA objects in Oracle schemas.

I slipped in some new features as well; I implemented the to_xml and compare methods on the CodeObject class, and Gerald now supports views in MySQL (as long as you are running 5.1 or above).

Finally, I changed the project documentation to use Sphinx.

Downloads are available at the PyPI page and the SourceForge project page.

If you find any problems or want to contribute any code just send me an email.

This release was at the request of the sqlpython project and contains only one change. A new convenience method connect has been added to the Schema class. This enables a schema to be initiated and then later have a database connection associated with it. Because this changes the public API of gerald I’ve released this under a new version number.

Development, bug and issue tracking and the project wiki are available on the project Trac site. Source code and distribution files are available at the sourceforge page.

The next release will be 0.4. Exactly what will make up that release is still evolving, although it is likely to feature SQL Server support as I have just started a new job and all of the systems there use it. To see what else is in the release and to track progress take a look at the version 0.4 roadmap.

The major component of this release was to add a ‘User’ class to the oracle_schema module. This is similar to the ‘Schema’ class but whilst that shows all of the objects a database user owns the ‘User’ class contains details of all of the objects they can access, including those owned by other database users. This was requested by the sqlpython project to enable them to use gerald for database introspection.

The only other change was to ensure that the NotImplementedError exception is raised in all of the super type methods that are just stubs. This is mainly in the Schema.py module and thus meant that I had to add a set of tests for this module.

Development, bug and issue tracking and the project wiki are available on the project Trac site. Source code and distribution files are available at the sourceforge page.

The next release will be 0.4. Exactly what will make up that release is still evolving. To see what is in the release and to track progress take a look at the version 0.4 roadmap.

• Ticket 17 – Views have been converted to dictionaries from tuples
• Ticket 18 – Reading an Oracle sequence updates it’s current value
• Ticket 19 – Postgres primary keys were not represented properly when read from the database

Development, bug and issue tracking and the project wiki are available on the project Trac site. Source code and distribution files are available at the sourceforge page.

The next release will be 0.3.5 and will introduce the concept of a ‘User’. This is similar to a ‘Schema’ but will reference all of the objects a database user can see even if they don’t own them. You can track progress for the release using the version 0.3.5 roadmap.

Gerald is being considered for use in the SQLPython toolkit. For them to get full value I will need to make a number of changes to the code. Luckily for all of us these were on the development roadmap anyway, so I’ve just moved them up the priority list.

As other people have shown an interest in the tool I have also invested in a little infrastructure and have fired up Trac for the sourceforge project. Gerald now has a wiki and, more importantly, a ticketing system for bug reports and feature requests. I’ve put the changes coming for release 0.3 in a number of tickets and you can track progress for the release using the version 0.3 roadmap.

• Fixed a bug in some connections to PostgreSQL
• Removed references to database links without passwords in Oracle
• Converted the package to use setuptools and from this release onward it is installable using easy_install

The last change was at the request of the SQLPython project, if you haven’t taken a look at that wonderful utility yet, please do. To support them it is likely that the next release of Gerald will support SQLite.

Please download, install and enjoy. Bug reports. tumultuous praise or cash bribes to the usual address please.

• My tumblog – is that even what they are called?
• Twitter – of course
• Plurk – although these messages may be suspiciously similar to my tweets
• Facebook – just to keep up with the juvenile party photos of people I went to university with
• Flickr – although most of the photos are restricted, if you want to see them drop me an email.

And you never know, I may actually post something technical here in the near future.

• Added support for comments on columns in Oracle
• Added support for comments on tables in Oracle
• Changed the stylesheet used for documentation
• Added more information to the README file and converted it to reStructured Text format

Please download, install and enjoy. Bug reports or tumultuous praise to the usual address please.

Anyone left is hopefully curious like I was to figure out the difference between ‘traditional’ oracle initialisation files (init.ora) and the new fangled server parameter files (sp files). Well wonder no further fair reader for I can explain all.

Prior to Oracle 9.2 (a long time ago in Oracle database years) it was only possible to permanently effect the configuration parameters of your database by changing the init.ora file and restarting your database instance. You could make changes whilst the database was running by using the ‘ALTER SYSTEM SET’ command but these would be lost the next time your database was restarted because the startup process would use the values in your init.ora file. This meant that any instance tuning would require some informed ‘twiddling’ by the DBA to settle on a suitable value for an instance parameter and that would then be followed by a restart, causing anyone using the database to be mightily inconvenienced.

With the introduction of server parameter files in 9.2 and above changes made interactively (using ‘ALTER SYSTEM SET’) are automatically persisted. This is because whenever a change is made this way it is automagically written to your spfile.

This article has a much more comprehensive description of the differences between the two different types of files. One of the useful things it mentions is the resolution order the database server uses to select an initialisation file on startup. This is;

• spfile<SID>.ora
• spfile.ora
• init<SID>.ora

Tick another thing off the list of ’stuff that has been bothering me and I need to figure out’.

• Numerous renames to more fully comply with PEP-8
• Added numerous tests, full details in the CHANGELOG.txt file
• Added an ‘enabled’ flag to table constraints (except in the MySQL module, because that database doesn’t support them)
• Added support for column defaults in Oracle
• Added a ‘table_name’ attribute to the schema.Trigger class
• Removed main and usage functions from each module that shouldn’t be imported

Please download, install and enjoy. Bug reports or tumultuous praise to the usual address please.