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 Mon, 20 Jun 2005 12:21:29 GMT
Hi Martin,

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.

> b) as you suggest, introduce a new repository attribute for
> field-descriptor to define the "PK not initialized" semantics
> given a generic Object signature
>

How does the "PK not initialized"-check act together with the FK fields? 
E.g. if a user define null-check="-1" in the PK field, but does not 
declare a null-check in the FK-field of a 1:n reference? Should OJB 
check this on startup an throw an exception or should OJB "copy/inherit" 
the null-check to all FK fields?

Another part we have to check is the sql-generation. If a user define 
null-check="-1" then
- on insert/update/delete the column have to set to 'null' when the 
field have "-1" value
- when reading the ResultSet a 'null' value have to be "translated" to 
"-1" as field value


> To me "null-value" sounds a bit confusing, maybe something like
> "unset-check", "null-check", "uninitialized-check"?
> Any more clever suggestions? :)
>

Here is my ranking list:

1. null-check
1. unset-check
(+1 for both names)
3. uninitialized-check

regards,
Armin


> 
> I quote the original message below so that people not following the
> user's list can get up to speed:
> 
>> Martin Kalén wrote:
>>
>>> Greetings,
>>>  after updating my local codebase with Jakob's latest fixes for applying
>>> FieldConversion classes internally I am having problems with PB-API 
>>> delete()
>>> calls.
>>>
>>> I have successfully been able to remove all work-arounds for 'manually'
>>> applying FieldConversions when reading trigger-set values back from DB
>>> and in ReportQuery result collections -- the new code simplifies PB-API
>>> usage a lot in these cases (if using FieldConversions)!
>>>
>>>
>>> However; I got stuck on the following - any hints, ideas or suggestions?
>>>
>>> I am storing an object with a composite PK where one column is allowed
>>> to contain numeric 0 values. INSERT and UPDATE are OK but DELETE fails
>>> with "Cannot delete object without valid PKs." because the check
>>> assertValidPkForDelete in BrokerHelper calls representsNull on line 482
>>> and the Long(0) value is considered invalid...
>>>
>>> Complete invocation chain for the delete-blocking detection is:
>>> DelegatingPersistenceBroker#delete(Object)
>>> PersistenceBrokerImpl#delete(Object)
>>> PersistenceBrokerImpl#delete(Object, boolean=false)
>>> PersistenceBrokerImpl#doDelete(Object, boolean=false)
>>> BrokerHelper#assertValidPkForDelete(ClassDescriptor, Object)
>>> BrokerHelper#representsNull(FieldDescriptor, Object)
>>>
>>> The check that fails is line 273 of BrokerHelper rev 1.57.2.17,
>>> since the object field is a long (ie type=primitive) and value
>>> is instance of Number with longValue=0.
>>>
>>> IMO the representsNull definition is wrong, since 0 as PK might very
>>> well be OK. Am I overlooking something?
>>>
>>>
>>> OJB-version is from CVS, OJB_1_0_RELEASE branch and DB is Oracle9i.
>>>
>>> DDL:
>>>  CREATE TABLE G (
>>>     O_ID NUMBER(14,0) NOT NULL,
>>>     G_ID NUMBER(4,0) NOT NULL,
>>>     ...
>>>     CONSTRAINT G_PK PRIMARY KEY (GEOMETRI_ID, OBJEKT_ID)
>>>  );
>>>
>>> Repository mapping:
>>>  <field-descriptor column="G_ID" name="gId" jdbc-type="NUMERIC" 
>>> primarykey="true" 
>>> conversion="...NonNullBigDecimal2longFieldConversion"/>
>>>  <field-descriptor column="O_ID" name="oId" jdbc-type="NUMERIC" 
>>> primarykey="true"/>
>>>
>>> Object fields:
>>>  private long oId;
>>>  private long gId;
>>>
>>> Field conversion:
>>>  public class NonNullBigDecimal2longFieldConversion implements 
>>> FieldConversion {
>>>
>>>   public Object javaToSql(Object obj) {
>>>     return obj;
>>>   }
>>>
>>>   public Object sqlToJava(Object o) {
>>>     if (o == null) {
>>>       return null;
>>>     }
>>>     if (o instanceof Number) {
>>>       return new Long(((Number) o).longValue());
>>>     }
>>>     throw new ConversionException("Error: Couldn´t convert BigDecimal 
>>> to long");
>>>    }
>>>
>>>  }
> 
> 
> Regards,
>  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