Mailing-List: contact ojb-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Users List" <ojb-user@db.apache.org>
Message-ID: <42B6904E.2050002@apache.org>
Date: Mon, 20 Jun 2005 11:45:50 +0200
From: Armin Waibel <arminw@apache.org>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: OJB Users List <ojb-user@db.apache.org>
Subject: Re: [PB-API] Problem with assertValidPkForDelete and Long(0) as PK
References: <42B68B91.50109@apache.org>
In-Reply-To: <42B68B91.50109@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi Martin,

I would suggest to source out the "representsNull" check in a separate 
pluggable service class to allow user to implement their own checks and 
to introduce a new attribute "null-value" in field-descriptor to allow 
user-specific "null values" (e.g. -1, 0, "null", ...).

regards,
Armin


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

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