Oracle (Prod) vs Derby(Test)-- hibeante exceptions

massaka · **Joined:** Wed Jan 22, 2014 3:19 am **Posts:** 4

Hello,

I'm using hibernate with oracle in production mode. In tests i'm trying to use derby memory database.

when i launches my tests i have this exception:

java.lang.ClassCastException: java.math.BigInteger cannot be cast to java.math.BigDecimal

I know that the cause is that Hibernate maps long Ids variables as DECIMAL and derby maps them as BIGINT, and in all my DAOs i'm casting to BidDecimal..

Is there any way to force hibernate or derby (custum dialects??) to avoid me changing the code in my DAOS (some 60 DAOs)..

Many thanks by advance

sanne.grinovero · **Posted:** Wed Jan 22, 2014 4:41 am

Right, you could use a Dialect.
Implementing a new one is very simple, just look at this table:
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#configuration-optional-dialects

So you know the class name; then open the source code of them and use it as an example.

BTW if you're just looking for a Java based database for easy testing, look at H2: already has very very complete support for Hibernate.
http://www.h2database.com/html/main.html

But if you really prefer to stick with Derby, please contribute the new dialect! We'd be happy to include it on the list, it's not there yet just because nobody seems to be motivated enough to make one.

massaka · **Joined:** Wed Jan 22, 2014 3:19 am **Posts:** 4

Thanks for answer..

I tried H2 ..but i faced the same problem, H2 also maps Long to BigInteger (http://www.h2database.com/html/datatypes.html)

I'm not sure from where to begin to write a custom dialect for Derby memory DB that will map Long to DECIMAL..

Do you have an example , ?

Many thanks

sanne.grinovero · **Posted:** Wed Jan 22, 2014 4:56 am

I'm pretty sure it works fine in our thousands of tests,
so it's probably a setup problem.

Did you set the Dialect?

Code:

hibernate.dialect org.hibernate.dialect.H2Dialect

massaka · **Joined:** Wed Jan 22, 2014 3:19 am **Posts:** 4

yes i did..
I will try to explain..

In one of my DAOs i have this line :

Code:

entity.setIdentifier(((BigDecimal) data[0]).longValue());

data is an Object class retrieved from JDBC request..

When i try to test this with Derby or H2 i have :

Code:

 java.lang.ClassCastException: java.math.BigInteger cannot be cast to java.math.BigDecimal

Normal , because H2 or Derby JDBC retreives BigInteger Object and not BigDecimal..

How to write a custom derby dialect to let DERBY JDBC retrieve BigDecimal as oracle's one?

sanne.grinovero · **Posted:** Wed Jan 22, 2014 5:21 am

well if it's JDBC request you make directly, Hibernate has nothing to do with it.
If you want Hibernate to map things automatically you should use an HQL query.

massaka · **Joined:** Wed Jan 22, 2014 3:19 am **Posts:** 4

well we choose deliberately not use HQL for performance issues (sorry if i offend u..) :

http://premaseem.wordpress.com/2011/09/07/hibernate-vs-native-sql-execution-time-profoling/

This is why i'm looking to know is there any way to write a custom dialect that maps Long into DECIMAL , is that possible? easy to do or very complexe?

Many thanks

sanne.grinovero · **Posted:** Wed Jan 22, 2014 6:03 am

I'm afraid you're confused: if you use SQL natively, then you're deliberately bypassing Hiberate, and you're bypassing any Dialect too. It won't be able to do ANY type conversion for you, as you disabled it.

BTW I'm not offended at all, in some cases SQL is a better choice. Still, don't fool yourself with those metrics as the difference is not that big in the real world, and also it's not a general rule that applies to all queries.

Hibernate is improving on performance every single day so if you care about performance you'd probably want to use the very latest versions and stick with HQL: only switch to SQL if you happen to diagnose an actual problem with a specific query.

I'd not recommend HQL to everyone in all cases, but if you have trouble with type conversions then it's definitely a better choice for your case.

Finally, consider that a good deal of the "performance hit" that you get from using HQL is *because of* type conversions. If you end up doing your own type conversion on top of SQL, you 'll probably end up being slower unless you craft your code very carefully.