[rules-dev] validator

[Mark Proctor]

I'm thinking about an ontology constraint system, based around field 
setter validation. However I cannot decide how to handle invalid changes 
in a consequence or in external java code. I'll may leverage the JSR 303 
- Bean Validation - http://jcp.org/en/jsr/detail?id=303.

Although I have several concerns with the spec, one is that it always 
validates objects and passes in the field as an object - with primitive 
intensive stuff that can add an overhead, due to auto boxing. I'm more 
tempted to pass in the main Object itself and users can then use the 
FieldExtractor to read the field as they require, either as an Object or 
a primitive with full co-ercion - the FieldExtractor would be injected. 
Further to that I can't see how you would make the validator session 
aware, and doing it via constructor injection would mean a validator per 
session which is not desirable. I spoke to the spec lead and he 
mentioned using LocalThread variables. However we can have multiple 
sessions in the same thread, just not executing at the same time, which 
means the current executing session would need to set itself on that 
localthread variable - basically context switching, which I don't like.

We should have a variable that lists the validator errors for the 
current working memory action phase, for user interrogation - much like 
Hibernate Validator (RI for JSR 303) allows you to list validation 
errors on a insert or update on a session.

But in rule engines we have other considerations:
The first fundamental question is do we allow invalid changes or do we 
always roll them back? My prefernce, much like a database, is the data 
model as seen by the engine is always valid.

Now if we assume the invalid change must be rolled bank or not applied 
how do we expose this to the user:
-Throw an exception, up to them if they catch and it will exit the 
engine if not caught.
-Do nothing, roll back the change and continue executing the consequence 
as normal, they can check the validator variable if they need to.
Allow for "catch" like blocks either after each modify block, or after 
the "then" block. Do we have one large catch block, or do we have some 
sort of type matching....

Currently my preference is for a "catch" block after the "then" block. 
I'm tempted to just have one large catch block and users can do an 
iteration of the validator variable doing "if" checks; we can always add 
in type matching later. The catch block can either resume or throw an 
exception; on resumption it will attempt to validate the bean again, if 
it's changed, if it's still invalid the process repeats.

Mark