I have an existing database that i cannot change, unfortunately
they have used CHAR instead of VARCHAR, so we
are going to have to code around padding
issues.

I attempted to remedy this by using a view and using
TRIM to get rid of the padding, however when I do
an insert on the trimmed fields I get:

[WARN] JDBCExceptionReporter - -SQL Error: 1733, SQLState: 42000
[ERROR] JDBCExceptionReporter - -ORA-01733: virtual column not allowed here

I take this to mean that when trimimming those fields the database lost
the link to the underlying table. If I remove the trim statments
from the view inserts work correctly.

Any Ideas? Strategies to get around this issues?

Raj

I suppose you just can't insert into a view created like that. Why don't you just use a custom UserType and handle the trimming on the java side?

According to me, the safest and easiest way to handle this situation is to use a custom type that would trim your string...

Have a look at http://forum.hibernate.org/viewtopic.php?t=925916&highlight=trim

Ooops, sorry gloeglm - we were posting at the same time ;-)

No Problem, better twice the same answer than no answer ;) PS: Nice to see another one reach the 100 posts - keep up posting :)

I can wire in an Interceptor to do all the trimming for me, but that
still doesn't help me.

When I do queries with prepared statement, they query parameters
have to be paddes as well.

The funny thing is If I don't use a prepared statement, but just
execute the sql string with a Statement the stuff that I'm querying
doesnt have to be padded with spaces.

Well you can have the userType trim the string before setting it in your objects, and have it fill up to a certain length before inserting into a query. Take a look at a simple type like net.sf.hibernate.type.StringType or some UserType examples in the forum and on the website. I am pretty sure this will solve your problem.

(Arrghhh - you have been faster again - force me to rewrite my post ;-)

I agree with gloeglm's approach. A few extra words however:

* For the queries, why not using a LIKE comparaison instead of a strict equal ?

* Otherwise, the padding approach is what I was busy writing before I saw gloeglm's post... Two remarks:

- the length of the field (for the padding) could be obtained from Hibernate's meta info;
- when querying, you can assign your parameters by forcing the type to your custom type. This way your value would be padded with blanks and an exact match *may* work.

(have never tried this approach however ;-)

That would be really sweet ... I don't think however there is a nice API for this, or do you know a easy way?

I had a look and unfortunately, the Hibernate metadata do not contain the field length (only its type).
Anyway, so far Hibernate creates a new instance every time a UserType is used in the mapping file - so you have one instance per field.
The field length could be obtained from the JDBC PrepareStatement or Resultset the first time the UserType is used.

The metadata available via Configuration includes length information.