Hi Martin,
Long time no see!
Martin Kalén wrote:
Greetings Armin and others,
now I finally have some allocated time to see this through.
Armin Waibel wrote:
Martin Kalén wrote:
I propose that we:
a) reduce the default representsNull semantics in BrokerHelper to a
minimal is null check (if even that)
Maybe we should source out all "PK/FK is null" stuff from BrokerHelper
to a pluggable class "NullCheck?"
hasNullPKField(ClassDescriptor cld, Object obj)
representsNull(FieldDescriptor fld, Object aValue)
assertValidPksForStore(FieldDescriptor[] fieldDescriptors, Object[]
pkValues)
assertValidPkForDelete(ClassDescriptor cld, Object obj)
because BrokerHelper is a conglomeration of "unassigned" methods and
get bigger and bigger, but in this case we can bundle methods into
coherence.
I have successfully tried a minimalistic approach of this which worked
very well. The interface is called NullCheck and has only one method:
/**
* Returns wether the given object value represents 'null' for the
specified field.
* @param fld descriptor representation of the persistent field
* @param aValue the value to check if it represents 'null'
* @return true if and only if aValue represents null
*/
boolean representsNull(FieldDescriptor fld, Object aValue);
Since the other BrokerHelper methods make their definitions based on
"representsNull" this is the only one that really needs to be factored out.
I know that at least Armin usually does not like more attributes in
repository.xml, but this time I will try to make you accept an exception
to the rule. :) Since null-check configuration is very similar to
conversion, I propose the following DTD change for <field-descriptor/>:
The null-check attribute contains a fully qualified class name.
This class must implement the interface
org.apache.ojb.broker.accesslayer.NullCheck.
A NullCheck can be used to implement special requirements for
the definitions of a field's 'null' value as Java representation.
null-check CDATA #IMPLIED
an alternative would be to use a custom attribute "null-check" in
field-descriptor (then we don't need to change the dtd). But I agree
that a new attribute will be more transparent.
What about OJB's xdoclet module, do we need to adapt the @ojb.field tag too?
I have create two implementations, NullCheckDefaultImpl containing
the old code from BrokerHelper (this is the default if @null-check
is not specified) and NullCheckRelaxedImpl:
public boolean representsNull(FieldDescriptor fld, Object aValue) {
return aValue == null;
}
The relaxed version works perfectly for my use-case where a primary
key numeric field is represented by a Java Long, is not nullable
but where id=0 is a valid db-value that should not trigger sequence
autonumbering or any delete/insert checks in OJB.
Any comments on this? I will create a JIRA issue and attach some
comments and code to track this issue for OJB 1.0.5.
What about the FK fields? These fields have to reflect the same behavior
as the PK fields. Do you expect that the user defines the same
"null-check" attribute in all FK fields of the referenced objects? If
this is the case we should add some kind of "check" (check if the PK
field and FK field use the same NullCheck implementation, if not log an
error msg or throw an exception) when OJB collects the FK fields of a
reference the first time.
BTW, what's the currently endorsed strategy for additions like this?
We don't have a strategy (we decide as the case arises).
regards,
Armin
This is an old very close-to-1.0.4 patch so I would like to start
adding it for a 1.0.5 release and then forward-merge to 1.1.
If OJB 1.1 is close to release I guess this strategy is a
bit backwards? :)
Cheers,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
