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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
