It's a bit difficult to pick the correct title for the thing that I'm going to write :) It's about having your POJO generated by hibernate and then feed it to h:dataTable.
When your object has a collection properties and the elements contained are unique within the collection, hibernate will create a Set to contains it. The thing with a Set is h:dataTable just can't accept it. The simplest solution is to change Set to Collection object and h:dataTable can accept it and Hibernate won't complain about it :)
Tuesday, September 14, 2010
Rolling back transaction (Seam managed transaction)
JSF+Seam is what I'm learning at the moment. And the case is I need to rollback the transaction due to business exception but I don't want to not catch the transaction (when a runtime exception is uncaught the transaction will be rollback automatically). The business exception here is a new exception class extending RuntimeException.
At first try, I add ApplicationException annotation with rollback = true in my BusinessException class. The controller class which invokes the business service class and under certain condition an exception of BusinessException type is thrown. In my scenario my transaction should be rolled back, the thing is... it was not rolled back.
This forced me to dive into seam's code (that's why I love open source) and find out how to handle the transaction. And I came into Transaction class, which I can use to do what I want.
Here's how to use it to mark the transaction as rollback:
Transaction.instance().rollback();
Actually all I wish is when the exception is thrown by the service class (already registered to seam) the transaction will be rolled back automatically, unfortunately for me it doesn't work :(
At first try, I add ApplicationException annotation with rollback = true in my BusinessException class. The controller class which invokes the business service class and under certain condition an exception of BusinessException type is thrown. In my scenario my transaction should be rolled back, the thing is... it was not rolled back.
This forced me to dive into seam's code (that's why I love open source) and find out how to handle the transaction. And I came into Transaction class, which I can use to do what I want.
Here's how to use it to mark the transaction as rollback:
Transaction.instance().rollback();
Actually all I wish is when the exception is thrown by the service class (already registered to seam) the transaction will be rolled back automatically, unfortunately for me it doesn't work :(
Entity inheritance-single table per class hierarchy strategy with JPA + Hibernate
I happened to have the chance to implement entity inheritance using single table per class hierarchy strategy. At first I though I would sail smooth and arrive at the promised land easily :) but as usual with programming, it is a rare thing a code would sail smooth at the first time.
Persisting entity works like charm, retrieving it makes me speechless. Here's an example:
The base class (ItemReference)
Subclass#1 (ItemReferenceAge)
Subclass#2 (ItemReferenceSex)
DDL
One class that I don't include here is the class which has a collection of ItemReferenceSex and a collection of ItemReferenceAge, let's call this class Wrapper.
The scenario is I add 2 instances of ItemReferenceAge to wrapper collection and persisted it. What happened when I try to load the same wrapper instance is both collections are having elements in them. Remember, I only add ItemReferenceAge instance which means the collection of ItemReferenceSex should be empty.
Looking at the query generated shows that the discriminator column is not used in the where clause of the select query. What I can think of the design reasoning is that it is assumed that there will not be two or more type of instances loaded in the same parent object which in my case it is.
Luckily for me, there's a solution for this and unfortunately it's hibernate specific annotation (is it maybe because of JPA doesn't state how to handle my case or is it hibernate implementation?). All I need to do is to add ForceDiscriminator annotation in my base class and the problem is solved!
Persisting entity works like charm, retrieving it makes me speechless. Here's an example:
The base class (ItemReference)
Subclass#1 (ItemReferenceAge)
Subclass#2 (ItemReferenceSex)
DDL
One class that I don't include here is the class which has a collection of ItemReferenceSex and a collection of ItemReferenceAge, let's call this class Wrapper.
The scenario is I add 2 instances of ItemReferenceAge to wrapper collection and persisted it. What happened when I try to load the same wrapper instance is both collections are having elements in them. Remember, I only add ItemReferenceAge instance which means the collection of ItemReferenceSex should be empty.
Looking at the query generated shows that the discriminator column is not used in the where clause of the select query. What I can think of the design reasoning is that it is assumed that there will not be two or more type of instances loaded in the same parent object which in my case it is.
Luckily for me, there's a solution for this and unfortunately it's hibernate specific annotation (is it maybe because of JPA doesn't state how to handle my case or is it hibernate implementation?). All I need to do is to add ForceDiscriminator annotation in my base class and the problem is solved!
Subscribe to:
Posts (Atom)
