For String properties that may contain more than 255 characters, it is advised to add a @Lob annotation to the appropriate property. For example, to keep a comment text in an entity, one would write:

@Lob
public String getComment() { return comment; }
public void setComment(String comment) { this.comment = comment; }

On PostgreSQL, a large string is usually kept in a TEXT column (instead of VARCHAR). However, after updating to Hibernate 3.6, an exception was suddenly thrown when accessing such a property (along with an SQLState: 22003 from PostgreSQL):

org.postgresql.util.PSQLException: Bad value for type long : This is some text...
	at org.postgresql.jdbc2.AbstractJdbc2ResultSet.toLong(AbstractJdbc2ResultSet.java:2796)
	at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getLong(AbstractJdbc2ResultSet.java:2019)
	at org.postgresql.jdbc4.Jdbc4ResultSet.getClob(Jdbc4ResultSet.java:43)
	at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getClob(AbstractJdbc2ResultSet.java:384)
        ... and more

Obviously, the PostgreSQL connector tried to interprete the textual content as a long integer now, which – of course – results in a failure. PostgreSQL knows two ways of storing binary large objects, either as BYTEA within the table space, or as OID in a separate place and referenced by a numerical identifier. It seems that Hibernate 3.6 suddenly treats TEXT columns like OID columns as well.

In the internet, I have found similar problems related to @Lob annotated byte[] properties. A common solution was to add a @Type annotation to the property.

An attempt to add @Type(type = “org.hibernate.type.MaterializedClobType”) did not help at all. Instead, @Type(type = “org.hibernate.type.TextType”) did the trick:

@Lob
@Type(type = "org.hibernate.type.TextType")
public String getComment() { return comment; }
public void setComment(String comment) { this.comment = comment; }

For PostgreSQL, it now works fine again, even without needing to alter the table column type. However I couldn’t check the impact of the annotation on other DBMS (like Oracle). Your feedback is welcome.

Der nach den Querelen mit Oracle entstandene Open Office-Fork LibreOffice erfreut sich einer weiter zunehmenden Beliebtheit. Dass es ab Fedora 15 das vorinstallierte Office-Paket sein wird, gilt als sicher. Auch Ubuntu hat sich für LibreOffice entschieden, Canonical hat außerdem einen Entwickler für das Projekt abgestellt.

Um die Stiftung nun auch finanziell auf eigene Beine zu stellen, sammelt die OpenOffice.org Deutschland e.V. Spendengelder. Bevorzugt soll die Stiftung in Deutschland eingetragen werden, da sie so “die größtmögliche Stabilität garantiert - nicht nur für Anwender, sondern auch für Entwickler, Firmen und Behörden.” Das deutsche Recht verlangt allerdings einen Kapitalstock von mindestens 50.000 Euro. Dieser soll bis zum 21. März eingesammelt sein. Ein hohes Ziel, von dem die Foundation allerdings mittlerweile “nur” noch knapp 5.000 Euro entfernt ist.

Die OpenOffice.org Deutschland e.V. ist nach eigener Aussage ein gemeinnütziger Verein, so dass alle Spenden in Deutschland steuerlich geltend gemacht werden können.