Sunday, 26 October 2008

URI "file:./" is not hierarchical

Just recently I came across the following exception when deploying a simple Grails application to Tomcat:

URI "file:./" is not hierarchical

The application was so simple and ran locally on tomcat-6.0.16 - it had to be something environmental. Comparing the differences between machines showed that it was the JVM that was different.

The JVM that produced the error was:

java version "1.5.0"
gij (GNU libgcj) version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)

while the Sun JRE 1.6 was okay:

java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode)

Note that this occurred on Ubuntu 8.04 64 bit Linux:

Linux dev 2.6.24-21-generic #1 SMP Mon Aug 25 16:57:51 UTC 2008 x86_64 GNU/Linux

Tuesday, 21 October 2008

Somewhere to put the code

I've written a lot of code in the past, and lost a lot of code over the years too. To prevent losing anymore and to help organise things, I've set up a repository at

There's not a lot there at the moment, just a linux script to extract the audio from an MP4, and a groovy script to extract a specified database from a mysqldump file:

I've tried to keep everything self contained - documentation is in the code - and hopefully someone else will find the contents useful. I also hope it will grow and become more useful over time, but time is the problem - there is so little of it...

Saturday, 18 October 2008

ST_Intersects performance

I was just using a query which made use of the ST_INTERSECTS function:
select * from table1 where st_intersects(st_point( ?, ?, 1),shape)=1
With the data I had, this query took 30 seconds! Before launching into an investigation to find out why, I just decided to swap the parameters - this made all the difference:
select * from table1 where st_intersects(shape, st_point( ?, ?, 1))=1
Now the query returns instantly! I'm no database expert, so investigating why the first version of the query took so long would have been a waste of valuable time - when such a simple solution was at hand.

Saturday, 11 October 2008

Finding table differences in Oracle

Often there is a need to compare two databases and see the differences. I come across this a lot when releasing a new build into an existing environment - the new code runs on the development database, but the test environment needs a schema upgrade before the code will run.

There are tools that will compare schemas for you, but sometimes I just need to quickly find out what columns are missing from the target schema (this is particularly useful when comparing different development schemas and you want to quickly implement changes - production releases need much better quality control than this).

The sql below provides one solution - showing the columns that are missing from 'owner1' when compared to 'owner2' for tables that match the prefix:

This will ofcourse identify missing tables. It's primative, but its an easy way to see basic structural differences using SQL - without the need for expensive tools. Since it is basic sql, you could include this as part of an environment verification test suite, or include in your application startup procedure - providing you have access to a reference schema for comparison.