Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » Zero = invalid primary key
Zero = invalid primary key [message #387929] Tue, 19 May 2009 08:21 Go to next message
Markus KARG is currently offline Markus KARGFriend
Messages: 44
Registered: July 2009
Member
I noticed that EclipseLink 1.1.1 does not accept zero as a valid primary
key. This is rather odd, since zero obviously is an integer just like 1
or -1 are, and AFAIK the JPA specification does NOT restrict the validity of
integer to those numbers larger than zero. As a result, an application (or
even worse: existing database with existing numbering already using zero)
must be tweaked specifically for EclipseLink. There are lots of databases
out there using zero or even negative numbers as primary keys, and an
untweaked application will not be able anymore to run on those, when using
EclipseLink. The default of a RI should always be to work without any
additional tweaks. So why isn't there a property that defaults the
zero-treatment to "zero is a valid integer" if not explicitly set? And how
to switch to this behaviour in the current EclipseLink without changing my
application?

Thanks
Markus
Re: Zero = invalid primary key [message #387942 is a reply to message #387929] Tue, 19 May 2009 18:54 Go to previous messageGo to next message
James Sutherland is currently offline James SutherlandFriend
Messages: 1939
Registered: July 2009
Location: Ottawa, Canada
Senior Member

0 is extremely common to be used as the default unassigned id value for a
generated Id, (long or int). For a primitive long/int you cannot assign
the value to null, only 0, so unless it is assumed for 0 to mean null,
then EclipseLink cannot know if an object is new or not, which requires an
extra database access to see if the row exists on the database, and can
lead to identity issues. So by default if the Entity has a "single" Id
value of type "int" or "long" only, then it is assumed that 0 means null.

EclipseLink fully supports using 0 as the Id value, you just need to
configure the setting,
"eclipselink.allow-zero-id"

Using a 0 as a valid Id value is very odd case, and it is desired for
EclipseLink to have optimized performance for the common cases, not to
have poor performance in general because of one exceptional case that can
easily be configured for.

---
James
http://www.nabble.com/EclipseLink---Users-f26658.html


James : Wiki : Book : Blog : Twitter
Re: Zero = invalid primary key [message #388425 is a reply to message #387942] Tue, 26 May 2009 07:36 Go to previous messageGo to next message
Markus KARG is currently offline Markus KARGFriend
Messages: 44
Registered: July 2009
Member
James,

while I always appreciate your honourable opinion, I need to disagree to
your argumentation here:

* For a reference implementation, which EclipseLink obviously is, the top
most priority should always be specification compliance. The JPA
specification does not tell the API user in any single word that an API
implementor is allowed to mark any value to be an invalid value (here:
zero). So the default should be that zero is allowed. So defaulting to
restrict zero in my opinion is a violation of the specification, unless you
can convince Linda DeMichiel to write a sentence into the spec to make clear
to the programmer that there can be restricted values.

* I disagree that it is "common" to restrict zero. "Common" to what base?
All people implementing JPA API? -- maybe, but users of the spec do not know
what is common in the vendor's eyes. All people using autogenerated
values? -- not at all: I know lots of people using zero in conjunction with
database generated IDs (especially if using partition ranges to merge data
from different sites). See, I am a database administrator for twelve years
now and never restricted zero nor saw a database where zero is restricted
nor ever had a need to think about restriction. The ID is an int. Not an int
minus zero. So the target should not be what the EclipseLink team believes
what "common" means, but what is written explicitly in the JPA
specification. Even if you would be right and it would be "common" to any
hypothetical base of people: The target of the RI is to match the spec, not
to match any "common sense" (if that would be the case, we wouldn't need a
spec for the most part). If EclipseLink needs this, please force Sun to
change the spec.

* There are lots of legacy databases out there which already use zero as a
valid value, and which are using database generated IDs. There are lots of
applications using those databases. Do you really want to enforce all
application vendors and all database administrators to change their existing
databases and applications (including renumbering of existing data) just to
enable EclipseLink to run ontop of them (you said that enabling the zero
feature would impose identity problems)? I think virtually nobody will do
that. As the top priority for a product should be compatibility, the default
should be the compatible setting, not the performance setting.

* Where is written in the user's documentation that one must set this
option? I did not find this. If you default to restrict the sequence of
numbers, you should at least put a fat warning in the user's documentation
right at the front page. No database administrator will know otherwise that
he must not provide a partition range which covers zero, and no application
programmer will know that he must not provide zero as a non-generated valued
(which actually fails in EclipseLink 1.1.1 in some cases, as I just
noticed!).

* It is not true that allowing zero automatically imposes a performance
penalty. As long as an entity is not marked as @GeneratedValue, it can
safely assume that zero is a valid value (why shouldn't it, TopLink also was
able to do it?), since it doesn't need to know whether or not a PK was
already generated. IF @GeneredValue is used, and only then, this is of any
interest. In that case, the solution is pretty easy: EclipseLink already
knows very well whether or not an instance is to be INSERTed or UPDATEd, and
only if the instance is to be INSERTed AND is marked as @GeneratedValue,
THEN (and only then) a new ID has to be generated. So I do not see the
problem EclipseLink seems to have in your argumentation. Why do you need
ANOTHER marker, besides the knowledge of wheter INSERT or UPDATE is to be
used? BTW, to be honest, throwing "Null primary key encountered in unit of
work clone" when NO @GeneratedValue is in place (this is what EclipseLink
currently, actually does is some cases) in my eyes is a bug since automatic
key generation is not a topic here at all -- it just breaks backwards
compatibility with applications and databases working pretty well on TopLink
and NOT using ANY generated value...!

As you see, there are a lot of arguments AGAINST defaulting to restriction
of zero. Can the EclipseLink team provide good arguments against them? At
least one that justifies why the EclipseLink team did not call Linda
DeMichiel and instruct her to add a simple sentence to the spec to make it
clear, like "A vendor is allowed to restrict the usage of zero as a primary
key due to performance reasons. Application programmers and database
adaministrators must live with the fact that they just cannot know whether
the actual provider allows or restricts zero."? I mean, how should
application vendors and database administrators know about it? And how
should a database vendor provide the usage of zero if for example the PK is
partitioned into ranges, where "by incident" one range spans from -500 to
500?

We are really in trouble with this, and we are not the only ones. Please
take my critics as serious warnings, not as personal attacks. My intention
is to make EclipseLink even better (it IS rather well already!), but for
this, I must clearly tell the EclipseLink team when it runs in the wrong
direction, of whatever reason.

Regards
Markus

"James " <james.sutherland@oracle.com> schrieb im Newsbeitrag
news:4ca90de08ff6eb8495969661bb7e2246$1@www.eclipse.org...
>0 is extremely common to be used as the default unassigned id value for a
>generated Id, (long or int). For a primitive long/int you cannot assign
>the value to null, only 0, so unless it is assumed for 0 to mean null, then
>EclipseLink cannot know if an object is new or not, which requires an extra
>database access to see if the row exists on the database, and can lead to
>identity issues. So by default if the Entity has a "single" Id value of
>type "int" or "long" only, then it is assumed that 0 means null.
>
> EclipseLink fully supports using 0 as the Id value, you just need to
> configure the setting,
> "eclipselink.allow-zero-id"
>
> Using a 0 as a valid Id value is very odd case, and it is desired for
> EclipseLink to have optimized performance for the common cases, not to
> have poor performance in general because of one exceptional case that can
> easily be configured for.
>
> ---
> James
> http://www.nabble.com/EclipseLink---Users-f26658.html
>
Re: Zero = invalid primary key [message #388426 is a reply to message #388425] Tue, 26 May 2009 07:57 Go to previous messageGo to next message
Markus KARG is currently offline Markus KARGFriend
Messages: 44
Registered: July 2009
Member
BTW, just added bug 277804 to the EclipseLink tracker
(https://bugs.eclipse.org/bugs/). As I mentioned, it just must be a bug that
I cannot use zero IDs even in case I do not use @GeneratedValue at all.

"Markus KARG" <karg@quipsy.de> schrieb im Newsbeitrag
news:gvg660$l05$1@build.eclipse.org...
> James,
>
> while I always appreciate your honourable opinion, I need to disagree to
> your argumentation here:
>
> * For a reference implementation, which EclipseLink obviously is, the top
> most priority should always be specification compliance. The JPA
> specification does not tell the API user in any single word that an API
> implementor is allowed to mark any value to be an invalid value (here:
> zero). So the default should be that zero is allowed. So defaulting to
> restrict zero in my opinion is a violation of the specification, unless
> you can convince Linda DeMichiel to write a sentence into the spec to make
> clear to the programmer that there can be restricted values.
>
> * I disagree that it is "common" to restrict zero. "Common" to what base?
> All people implementing JPA API? -- maybe, but users of the spec do not
> know what is common in the vendor's eyes. All people using autogenerated
> values? -- not at all: I know lots of people using zero in conjunction
> with database generated IDs (especially if using partition ranges to merge
> data from different sites). See, I am a database administrator for twelve
> years now and never restricted zero nor saw a database where zero is
> restricted nor ever had a need to think about restriction. The ID is an
> int. Not an int minus zero. So the target should not be what the
> EclipseLink team believes what "common" means, but what is written
> explicitly in the JPA specification. Even if you would be right and it
> would be "common" to any hypothetical base of people: The target of the RI
> is to match the spec, not to match any "common sense" (if that would be
> the case, we wouldn't need a spec for the most part). If EclipseLink needs
> this, please force Sun to change the spec.
>
> * There are lots of legacy databases out there which already use zero as a
> valid value, and which are using database generated IDs. There are lots of
> applications using those databases. Do you really want to enforce all
> application vendors and all database administrators to change their
> existing databases and applications (including renumbering of existing
> data) just to enable EclipseLink to run ontop of them (you said that
> enabling the zero feature would impose identity problems)? I think
> virtually nobody will do that. As the top priority for a product should be
> compatibility, the default should be the compatible setting, not the
> performance setting.
>
> * Where is written in the user's documentation that one must set this
> option? I did not find this. If you default to restrict the sequence of
> numbers, you should at least put a fat warning in the user's documentation
> right at the front page. No database administrator will know otherwise
> that he must not provide a partition range which covers zero, and no
> application programmer will know that he must not provide zero as a
> non-generated valued (which actually fails in EclipseLink 1.1.1 in some
> cases, as I just noticed!).
>
> * It is not true that allowing zero automatically imposes a performance
> penalty. As long as an entity is not marked as @GeneratedValue, it can
> safely assume that zero is a valid value (why shouldn't it, TopLink also
> was able to do it?), since it doesn't need to know whether or not a PK was
> already generated. IF @GeneredValue is used, and only then, this is of any
> interest. In that case, the solution is pretty easy: EclipseLink already
> knows very well whether or not an instance is to be INSERTed or UPDATEd,
> and only if the instance is to be INSERTed AND is marked as
> @GeneratedValue, THEN (and only then) a new ID has to be generated. So I
> do not see the problem EclipseLink seems to have in your argumentation.
> Why do you need ANOTHER marker, besides the knowledge of wheter INSERT or
> UPDATE is to be used? BTW, to be honest, throwing "Null primary key
> encountered in unit of work clone" when NO @GeneratedValue is in place
> (this is what EclipseLink currently, actually does is some cases) in my
> eyes is a bug since automatic key generation is not a topic here at all --
> it just breaks backwards compatibility with applications and databases
> working pretty well on TopLink and NOT using ANY generated value...!
>
> As you see, there are a lot of arguments AGAINST defaulting to restriction
> of zero. Can the EclipseLink team provide good arguments against them? At
> least one that justifies why the EclipseLink team did not call Linda
> DeMichiel and instruct her to add a simple sentence to the spec to make it
> clear, like "A vendor is allowed to restrict the usage of zero as a
> primary key due to performance reasons. Application programmers and
> database adaministrators must live with the fact that they just cannot
> know whether the actual provider allows or restricts zero."? I mean, how
> should application vendors and database administrators know about it? And
> how should a database vendor provide the usage of zero if for example the
> PK is partitioned into ranges, where "by incident" one range spans
> from -500 to 500?
>
> We are really in trouble with this, and we are not the only ones. Please
> take my critics as serious warnings, not as personal attacks. My intention
> is to make EclipseLink even better (it IS rather well already!), but for
> this, I must clearly tell the EclipseLink team when it runs in the wrong
> direction, of whatever reason.
>
> Regards
> Markus
>
> "James " <james.sutherland@oracle.com> schrieb im Newsbeitrag
> news:4ca90de08ff6eb8495969661bb7e2246$1@www.eclipse.org...
>>0 is extremely common to be used as the default unassigned id value for a
>>generated Id, (long or int). For a primitive long/int you cannot assign
>>the value to null, only 0, so unless it is assumed for 0 to mean null,
>>then EclipseLink cannot know if an object is new or not, which requires an
>>extra database access to see if the row exists on the database, and can
>>lead to identity issues. So by default if the Entity has a "single" Id
>>value of type "int" or "long" only, then it is assumed that 0 means null.
>>
>> EclipseLink fully supports using 0 as the Id value, you just need to
>> configure the setting,
>> "eclipselink.allow-zero-id"
>>
>> Using a 0 as a valid Id value is very odd case, and it is desired for
>> EclipseLink to have optimized performance for the common cases, not to
>> have poor performance in general because of one exceptional case that can
>> easily be configured for.
>>
>> ---
>> James
>> http://www.nabble.com/EclipseLink---Users-f26658.html
>>
>
>
Re: Zero = invalid primary key [message #388427 is a reply to message #387942] Tue, 26 May 2009 08:14 Go to previous messageGo to next message
Markus KARG is currently offline Markus KARGFriend
Messages: 44
Registered: July 2009
Member
James,

> EclipseLink fully supports using 0 as the Id value, you just need to
> configure the setting,
> "eclipselink.allow-zero-id"

do I understand correctly, all I need to do is adding the following line to
the persistence.xml and my application will work correctly again?

<property name="eclipselink.allow-zero-id" value="true"/>

Thanks
Markus
Re: Zero = invalid primary key [message #388431 is a reply to message #388425] Tue, 26 May 2009 13:43 Go to previous messageGo to next message
James Sutherland is currently offline James SutherlandFriend
Messages: 1939
Registered: July 2009
Location: Ottawa, Canada
Senior Member

First of all, EclipseLink fully allows support for 0 as a valid id value.
You just need to set a simple persistence.xml option. If Glassfish wishes
to do this by default, that is fine.

Second, the primary purpose of EclipseLink is not to be a "reference"
implementation. EclipseLink is a persistence product, well actually more
than just persistence as it supports XML, SDO and WebServices. It primary
purpose is to be a useful, high performance, and production quality
product for its users.

Third, if the Spec does not say something, then you can't go assuming it
is implying one thing or another, it is "undefined". Unless there is a
TCK test that requires some functionality that fails, then a JPA
implementation is by definition Spec compliant. If they Spec committee
feels strongly about allowing 0 as an id for objects with a singleton
primitive id, then they can have a TCK test added, and every JPA vendor
will be in the same boat.

I agree, that some users desire to use 0 id values for primitives
(although this is a generally risky thing to do, as a newly created object
will have the same id and identity as an existing object, which can cause
identity problems). So perhaps we should consider allowing 0 by default.

> EclipseLink already knows very well whether or not an instance is to be
INSERTed or UPDATEd

This is not true, EclipseLink does not know if an instance is new or not.
If its id is null, it knows it is new, otherwise on merge or even persist,
it must check the database.


James : Wiki : Book : Blog : Twitter
Re: Zero = invalid primary key [message #388432 is a reply to message #388427] Tue, 26 May 2009 13:43 Go to previous messageGo to next message
James Sutherland is currently offline James SutherlandFriend
Messages: 1939
Registered: July 2009
Location: Ottawa, Canada
Senior Member

Yes.

James : Wiki : Book : Blog : Twitter
Re: Zero = invalid primary key [message #388434 is a reply to message #388431] Tue, 26 May 2009 14:43 Go to previous messageGo to next message
Markus KARG is currently offline Markus KARGFriend
Messages: 44
Registered: July 2009
Member
James,

thank you for your comments.

> Third, if the Spec does not say something, then you can't go assuming it
> is implying one thing or another, it is "undefined". Unless there is a
> TCK test that requires some functionality that fails, then a JPA
> implementation is by definition Spec compliant. If they Spec committee
> feels strongly about allowing 0 as an id for objects with a singleton
> primitive id, then they can have a TCK test added, and every JPA vendor
> will be in the same boat.

I will suggest this to the spec lead. Obviously it is a point that needs to
get defined.

> I agree, that some users desire to use 0 id values for primitives
> (although this is a generally risky thing to do, as a newly created object
> will have the same id and identity as an existing object, which can cause
> identity problems). So perhaps we should consider allowing 0 by default.

Great. :-)

>> EclipseLink already knows very well whether or not an instance is to be
> INSERTed or UPDATEd
> This is not true, EclipseLink does not know if an instance is new or not.
> If its id is null, it knows it is new, otherwise on merge or even persist,
> it must check the database.

I see. So the solution to enable zero AND keep optimized performance might
be a simple enum for the persistence state which is either "NEW" (needs
INSERT), "DIRTY" (needs UPDATE) or "CLEAN" (nothing needed)?

Regards
Markus
Re: Zero = invalid primary key [message #388435 is a reply to message #388432] Tue, 26 May 2009 15:04 Go to previous messageGo to next message
Markus KARG is currently offline Markus KARGFriend
Messages: 44
Registered: July 2009
Member
"James " <james.sutherland@oracle.com> schrieb im Newsbeitrag
news:7a23f396a480c2e6c0ee73c85c2903e9$1@www.eclipse.org...
> Yes.

Thanks you very much, this seems to work! Great! :-)

Would be great if this line would be found in the documentation, because
(maybe I am blind) nowhere was told that (a) it is a property which can be
set in the persistence.xml, and (b) that the correct value is the string
"true"... (I really had to guess both).

Thanks
Markus
Re: Zero = invalid primary key [message #388436 is a reply to message #388435] Tue, 26 May 2009 19:56 Go to previous messageGo to next message
Doug Clarke is currently offline Doug ClarkeFriend
Messages: 155
Registered: July 2009
Senior Member
Tough to say where documenting that little gem would help. I have some
ideas but right now it only seems to be covered in the Java Docs

http://www.eclipse.org/eclipselink/api/1.1.1/org/eclipse/per sistence/config/PersistenceUnitProperties.html#ALLOW_ZERO_ID

And in there it lacks information about the allowed values. Can you open a
documentation bug on the issue and I'll add some comments about where this
can better addressed in the existing docs.

Doug
Re: Zero = invalid primary key [message #388439 is a reply to message #388436] Thu, 28 May 2009 14:02 Go to previous message
Markus KARG is currently offline Markus KARGFriend
Messages: 44
Registered: July 2009
Member
Doug,

as it worked in TopLink, I would suggest to add it here:
http://wiki.eclipse.org/EclipseLink/Examples/MigratingFromOr acleTopLink

also this is a good place
http://wiki.eclipse.org/Introduction_to_Java_Persistence_API _(ELUG)#persistence.xml_File

I have opened an item for that:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=278216

Regards
Markus

"Doug Clarke" <douglas.clarke@oracle.com> schrieb im Newsbeitrag
news:5453e82dc45fa7618d67f53d3490bc09$1@www.eclipse.org...
> Tough to say where documenting that little gem would help. I have some
> ideas but right now it only seems to be covered in the Java Docs
>
> http://www.eclipse.org/eclipselink/api/1.1.1/org/eclipse/per sistence/config/PersistenceUnitProperties.html#ALLOW_ZERO_ID
>
> And in there it lacks information about the allowed values. Can you open a
> documentation bug on the issue and I'll add some comments about where this
> can better addressed in the existing docs.
>
> Doug
>
Previous Topic:left join implementation for informix problem
Next Topic:List of Supertype and @OrderBy
Goto Forum:
  


Current Time: Fri Mar 29 01:24:59 GMT 2024

Powered by FUDForum. Page generated in 0.03560 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top