Bug 243947 - Provide improved configuration for descriptor configuration that allows PK of 0
Summary: Provide improved configuration for descriptor configuration that allows PK of 0
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Eclipselink (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: James Sutherland CLA
QA Contact:
URL:
Whiteboard:
Keywords: Documentation
Depends on:
Blocks:
 
Reported: 2008-08-12 18:14 EDT by Sebastien Tardif CLA
Modified: 2022-06-09 10:10 EDT (History)
3 users (show)

See Also:


Attachments
Patch to allow config on id-validation (35.18 KB, patch)
2009-01-15 16:05 EST, James Sutherland CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastien Tardif CLA 2008-08-12 18:14:56 EDT
Old Sequence behavior on "long id" by specifing null value in descriptor is broken by Rev 2000 under bug#220394 -improves insert performance.

I have an application that works in many previous version of TopLink.
However, on EclipseLink, it doesn't work anymore.

Most but not all of my domain objects use "long id" for mapped primary key. Default initialization in Java for long is 0. So our application 99% of all objects setup the mapping to tell that attribute "id"
"default null value" is Long == 0 using TopLink/EclipseLink workbench.

We do communicate to TopLink that id == 0 is equivalent to null but the new sequence code doesn't care anymore about what we specify. We see the new code has removing a feature and making the Workbench "default null value" feature most of the time useless in our case. 

You probably already heard of the "Null Pattern". That's why we avoid using Long instead of "long". With Java 5 it's even worst, if we use Long and some client code expect "long" Java will do an implicit cast but at runtime will throw NullPointerException.

It looks weird from the client code that we call assignSequenceNumber when our sequence field in not explicitly initialized and the method refuse to assign the sequence.

I really doubt that that checking what is the definition of null in the descriptor for the field involved can be visible in a profiler.

The guilty method is: 

    public Object assignSequenceNumber(Object object, AbstractSession
writeSession) throws DatabaseException {
        DatabaseField sequenceNumberField = this.descriptor.getSequenceNumberField();
        Object existingValue = getBaseValueForField(sequenceNumberField,
object);
        // If the value is null or zero (int/long) return.
        // PERF: The (internal) support for letting the sequence decide this was removed,
        // as anything other than primitive should allow null and default as such.
        if (existingValue != null &&
!Helper.isEquivalentToNull(existingValue)) {
            return null;
        }

   /**
     * Check if the value is null, or 0 (int/long) for primitive ids.
     */
    public static boolean isEquivalentToNull(Object value) {
        return (value == null)
                        || (!isZeroValidPrimaryKey
                                && (((value.getClass() ==
ClassConstants.LONG) && (((Long)value).longValue() == 0L))
                                        || ((value.getClass() ==
ClassConstants.INTEGER) && (((Integer)value).intValue() == 0))));
    }

https://bugs.eclipse.org/bugs/show_bug.cgi?id=233247
Comment 1 James Sutherland CLA 2008-08-14 10:07:32 EDT
Not sure I understand your current issue.

If you have an object with null or with 0 as its primary key a sequence will be assigned for it.  Are you seeing an object with a null or 0 primary not get a sequence number?

Or did you disable the global setting that allow 0 to be interpreted as null? Perhaps do not disable this globally, only for the classes that allow 0 as a primary key?
Comment 2 Sebastien Tardif CLA 2008-08-14 12:11:59 EDT
I have one mapped class that have long 0 for legal primary key.
For my other mapped classes long 0 is not a legal primary key.

So by default, with latest EclipseLink version, when I read my existing instance with legal long 0 for primary key, EclipseLink generate a validation error. Before in EclipseLink and TopLink, I didn't have this problem because my settings in the Workbench saying that my attribute representing the primary key has for null value -1 was respected.

So the new behavior create a regression. 

After a while after I create this bug I started to have some understanding of the new implementation. However, it's a downgrade because now I cannot define the behavior of my primary key in the workbench anymore.

So my point about "performance", because the change was about performance, is that the cost of reading the definition of the primary key in the mapping should be very low.

So we could bring back previous behavior respecting what is specified in the workbench for null value or if we prefer separate the two concepts create a new attribute in the workbench defining if 0 is a valid primary key.
Comment 3 James Sutherland CLA 2008-08-27 08:50:53 EDT
0 is no longer a valid primary key value by default in EclipseLink.  This was by design.  You can configure your descriptor to allow 0 primary key using the IdValidation.

Perhaps this bug should be change to make this configuration easier?

Adding annotation and XML support for this option.
Comment 4 James Sutherland CLA 2009-01-15 16:05:44 EST
Created attachment 122728 [details]
Patch to allow config on id-validation
Comment 5 James Sutherland CLA 2009-01-19 09:55:41 EST
Fixed
Comment 6 Eclipse Webmaster CLA 2022-06-09 10:10:55 EDT
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink