Mailing-List: contact ojb-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Users List" <ojb-user@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42B68B91.50109@apache.org>
Date: Mon, 20 Jun 2005 11:25:37 +0200
From: =?ISO-8859-1?Q?Martin_Kal=E9n?= <mkalen@apache.org>
Organization: ASF
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: OJB Users List <ojb-user@db.apache.org>
Subject: [PB-API] Problem with assertValidPkForDelete and Long(0) as PK
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org