Community
Participate
Working Groups
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
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?
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.
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.
Created attachment 122728 [details] Patch to allow config on id-validation
Fixed
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink