db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: [PB-API] Problem with assertValidPkForDelete and Long(0) as PK
Date Thu, 06 Apr 2006 01:41:39 GMT
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: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 

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


Mime
View raw message