Thomas Vandahl wrote:
Scott Eade wrote:
Since updating to the latest snapshot jar these fields are ending up
with zero values in the database.  Not much has changed since the
previous snapshot jar I was running - Thomas: is there any chance this
could be related to your recent intake changes?  I need to dig further,
but I'm too dead tired to look at this any more today (it's just gone
2:15am)

The only thing I changed was the order of operations so that now first
all fields are inited and then all fields are validated in two loops
whereas previously every field was inited and then validated in one
loop. I don't see that this could cause the described behavior.
The above problem is unrelated to either of our patches - it is a side effect of the fact that reflection is used by setProperties() that means that Intake is incapable of validating Integer fields where a null value needs to be distinguished from a zero.
I'm not entirely sure that your fix does what you want. As I see it, if
your field key is in the parameter parser, this means that the field was
meant to be set. The case "null" as a value should not happen then (The
parser takes care of this). If the value is empty (""), however, this
could well be meant as deleting a fields contents. This would now result
in this field not to be set - and not to be validated, if I'm not
mistaken. I'll try to make up a test case to prove this.
Actually, the problem is that isSet() currently controls whether or not a field is validated - the problem with my patch is that a required field that is not set is no longer being validated. The fix is to also check isRequired() when determining whether or not validation is required.

Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to