Update to Hibernate 3.5.6

[Nicklas Nordborg]

This started out as an update to Hibernate 3.5.2 but they have now released several other bugfix versions. The current one is 3.5.6.

[Nicklas Nordborg]

Argh! This was a bit more complicated than expected. The Hibernate team has started to redesign the type system and has deprecated a lot of static constants, methods and classes. The redesigned system will be included in 3.6. See ​http://opensource.atlassian.com/projects/hibernate/browse/HHH-5138 for a bit more information.

The topmost interface 'org.hibernate.type.Type' is kept, but it has a big structure of subinterfaces and subclasses that is about to change. The bad thing is that some classes (eg. NullableType) that we use and expose in our public API is removed in Hibernate 3.6. In other words, we are forced to make a binary incompatible change in our API if we ever want to update to Hibernate 3.6 in the future. I assume that we are going to do that sooner or later...

So... I'll deprecate affected places in the BASE API and will start to implement a wrapper class that tries to hide as much as possible of the Hibernate-internal stuff.

[Nicklas Nordborg]

I have investigated this a bit more. First a correction to the above comment. The NullableType seems to remain in Hibernate 3.6, but none of the actual subclasses (StringType, IntegerType, etc.) are extending from it anymore.

In any case, there are two methods in the BASE API that are affected:

• Type.getHibernateType()
• VirtualColumn.getType()

Both methods are now marked as deprecated and should be "replaced" by calls to Type.getTypeWrapper() and VirtualColumn.getTypeWrapper(). It is not a perfect replacement and, depending on the needs of the calling code, we may need to implement more functionality in the TypeWrapper class. Anyone experiencing problems due to this issue are encouraged to discuss this on the BASE developer mailing list. Under all circumstances it is important to stop using the deprecated methods.

[Nicklas Nordborg]

(In [5345]) Fixes #1488: Update to Hibernate 3.5.2

[Nicklas Nordborg]

(In [5346]) References #1488

[Nicklas Nordborg]

I have found a problem that appears when running the updated.sh script. There is a change in Hibernate (since 3.5.0-beta3: ​http://opensource.atlassian.com/projects/hibernate/browse/HHH-4457) that affects the sql that is generated for columns that are added to existing tables. If the new column has been mapped with not-null="true" Hibernate now adds a not null to the column declaration that wasn't included before. Here is an example for the BioPlateData.getBioPlateType() column which was added as part of #1442:

alter table `BioPlates` add column `bioplatetype_id` integer not null
...
alter table `BioPlates` 
  add index FK53772B2583EAB46E (`bioplatetype_id`),
  add constraint FK53772B2583EAB46E foreign key (`bioplatetype_id`) 
    references `BioPlateTypes` (`id`)

If there are existing rows in the BioPlates table, this statement fails in PostgreSQL since no default value is provided. MySQL sets the value in existing rows to '0', but fails later on when adding a foreign key constraint to the BioPlateTypes table since there is no record with id=0 in that table. The failures are not immediately detected since Hibernate swallows all errors from the schema update tool. But various runtime errors will appear later on.

One could argue that including the "not null" is correct because that is what we have specified in the mapping document, but the old behavior was a bit more convenient since it allowed us to add the new column without the "not null" constraint and later on in our own code we could add values to it.

So how can we fix this:

1. Change the mapping document to not-null="false". But this doesn't feel correct either since we don't want to allow null values. It will also affect checks that Hibernate makes.
2. Get rid of the not null in all alter table ... add column ... statements. Eg. revert back to the old behavior. This should be safe, but I don't know how we can intercept the SQL statements generated by Hibernate.
3. Add a default value to the update statement that points to an existing record in the foreign table. This is maybe the most correct solution but requires that we access the database before starting Hibernate and that we are able to modify the mapping programmatically after it has been loaded from the mapping xml files.

[Nicklas Nordborg]

(In [5386]) References #1482: Update to Hibernate 3.5.2

Installation program now detect problems with database generation and exits immediately.

[Nicklas Nordborg]

(In [5388]) References #1488: Update to Hibernate 3.5.2

Fixes problems with schema update by replacing the Hibernate tool with our own implementation. Most of the work is still done by Hibernate, but we now have the chance to modify or skip certain SQL statements.

[Nicklas Nordborg]

This started out as an update to Hibernate 3.5.2 but they have now released several other bugfix versions. The current one is 3.5.6.