Hello Mandy,
I had this problem as well. We hacked it via
Code:
@org.hibernate.annotations.SQLInsert(callable= true, sql="call newItem(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)")
To quote
http://www.hibernate.org/hib_docs/annot ... ml_single/ :
Quote:
The parameters order is important and is defined by the order Hibernate handle properties. You can see the expected order by enabling debug logging for the org.hibernate.persister.entity level. With this level enabled Hibernate will print out the static SQL that is used to create, update, delete etc. entities. (To see the expected sequence, remember to not include your custom SQL through annotations as that will override the Hibernate generated static sql.)
It was an ugly workaround. First we enabled SQL debug and watched hibernate insert to figure out the order in which hibernate passed its parameters to the insert statement. Then we coded a stored procedure that took those parameters in the order specified in hibernate's debug as input and rearranged the insert statement to please Oracle.
Unfortunately, the decision to use Oracle is out of the hands of my development team. However, the decision to use Hibernate is. We're going to be refactoring our code to use JPA and will switch to TopLink if this isn't fixed soon.
The order of the parameters changes from connection pool to connection pool making this ugly hack extra-brittle. It works in our production application, but fails in our unit tests. The only way to get this strategy fully working is to write a stored procedure for each connection method used (Spring in Junit, Tomcat pools, etc) and switch them somehow.
I see multiple problems in this scenario:
Why does oracle have this STUPID restriction if the first place?
I don't think it's unreasonable to expect Hibernate to work with CLOBs on international databases on modern versions of Oracle, even if this means following stupid rules dictated by Oracle.
I especially hate the SQLInsert annotation that doesn't let me specify the order of the fields. I can accept having to override hibernate's auto-magical behavior due to STUPID oracle rules. I don't appreciate such an unreasonable restriction on behalf of hibernate for something that I would see as a common use case.
I'd love to know if you (or anyone else) finds a better solution.
Thanks,
Steven
Login
FAQ
Search