Bug 536228 (RHQ-600)

For fields with database constraints, we need to be able to validate them before hitting constraint validation errors in the database (see e.g. RHQ-599 for an example)


15:57:59 < pilhuhn> jshaughn: I recall that you were looking at some validation frameworks in the past - was there any outcome?
15:59:59 < jshaughn> I think you are referring to  Hibernate Validator
16:01:21 < jshaughn> We lookd at this as a potential tool to massage (invalid) data on its way to the db.  But, Validator is not really intended for data manipulation, only strict validation. Meaning, it's purpose is to check a value, and throw exceptions as necessary.
16:01:50 < jshaughn> It is really flexible for that type of work, offering several built-in validators and easy extension.
16:02:14 < pilhuhn> ok
16:02:31 < jshaughn> If integrated into the GUI it can be a nice way of validating user input before it makes it deep into the code.
16:02:54 < pilhuhn> I am asking because of RHQ-599
16:03:57 < jshaughn> I had come up with an annotation-based mechanism for doing data manipulation for entities, but we didn't use it. It was designed to handle things like enforcing max-length and non-null constraints. 
16:05:08 < pilhuhn> Ok, so short term solution would be to do it "by hand"
16:05:24 < pilhuhn> We really need to look into this again for 2.1
16:05:58 < jshaughn> yup :(
16:06:15 < pilhuhn> Do you recall if there is a Jira?
16:06:47 < jshaughn> it was a val-too-long problem that prompted the whole thing I did.  In the end we opted to just increase the field size
16:08:29 < jshaughn> greg wasn't thrilled with adding a home-grown annotation mechanism.  There is no general "validation-mechanism" jira that I know of.
16:09:35 < jshaughn> I think someone said that certain types of constraint handling may be built into the next release of JPA, but I'm not sure
16:10:02 < pilhuhn> I added RHQ-600
16:10:51 < jshaughn> maybe we should clip this convo into a comment