Business Key Validation and Seam
gjeudy Feb 16, 2009 5:10 PMHi,
I'm using Seam 2.0.1.GA in a typical JBoss 4.2.2 setup. I hit a problem where I need to validate attempts to insert duplicate entries for a particular entity. I use the business key (which is not the same as the database surrogate key). That business key includes a date range which makes it impossible to enforce at the database level unless we code a trigger which we don't want.
So here I am trying to find a way to plug this validation in the Seam app layer.
Plan A
I could write custom validation as part of the business logic invoked in the INVOKE APPLICATION phase, the problem I have is since i'm operating in AUTO FLUSH mode and that the backing bean is also a hibernate managed entity I risk of flushing an invalid change to the database even after a validation failure.
I don't use MANUAL flush (now im thinking maybe I should) because I didnt want to worry about flushing and one requirement of the application is to commit changes often to avoid changes that are lost in an abandoned or timed out conversation so it made sense to keep AUTO flush.
Plan B
On the other hand it seems that locating my business key validation inside a JSF validator would keep the backing bean clean in case of a validation failure (therefore no risks of committing invalid data). I added a validator bound to a hidden field so that it is only triggered when the whole form is submitted.
The problem I find is that I need to lookup every single field from the JSF UI tree. Moreover the JSF UI Tree lookup logic will vary depending if we are validating inside a JSF dataTable or just a simple form or one of the more complex constructs like Richfaces listShuttle.
That seems doable but doesn't sound like a simple or elegant solution.
Plan C
Use DTO objects for backing beans, invoke validation in INVOKE APPLICATION phase, upon successful pass copy DTO to hibernate managed entities. Yuck...
All in all it seems like the logical solution would be Plan B.. I know that Beans Validation spec is evolving to address more complex validation scenarios but until we get there what can we do?
How others have tackle this common problem?
Thanks,
-Guillaume