The auto-increment field should be tested when in PK that is inherently not-null. In this case, there is no other way (exception if we create a nullable attribute for field-descriptors).
About the 0 in multi-pk fields, I agree. My comments look about single PK fields.
I'm just trying to get a new point of view in the discussion, because I use largelly int in PK, and changes in this behaviour can affect our projects (fortunatelly, since we never use 0 as valid value for PKs, we had no problems like reported by you)...
My propose is not change current behaviour, but add non-invasive options to manipulate behaviour of OJB.
May be docs should point the developer to use the conversion when he want's the mapping from 0 to null, and make OJB doens't making this conversion automatically, BUT in case of auto-increment fields I don't see much scape. A declared int field will be 0 even if the value is not set... So how can I inform OJB that this is a new field? Should we take in count that this is a multi-pk, 0 is not converted? Maybe the simple to understand, an less intrusive make OJB:
a) don't convert automatically 0 to null; b) when auto-increment is set, consider 0 as new auto-calculated value. c) convert 0 to null and vice-versa when using int2IntegerConversion.
Best regards,
Edson Richter
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
