db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kalén <mka...@apache.org>
Subject Re: [PB-API] Problem with assertValidPkForDelete and Long(0) as PK
Date Tue, 04 Apr 2006 16:33:17 GMT
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
	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

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.

BTW, what's the currently endorsed strategy for additions like this?
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? :)


To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message