Armin Waibel wrote:
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", ...).
This sounds like the best solution! It's in line with other OJB functional
areas, ie it fits nicely together with the FieldConversion concept.
I propose that we:
a) reduce the default representsNull semantics in BrokerHelper to a
minimal is null check (if even that)
b) as you suggest, introduce a new repository attribute for
field-descriptor to define the "PK not initialized" semantics
given a generic Object signature
To me "null-value" sounds a bit confusing, maybe something like
"unset-check", "null-check", "uninitialized-check"?
Any more clever suggestions? :)
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
