Re: Obscure Primary Key Gotcha
Re: Obscure Primary Key Gotcha
- Subject: Re: Obscure Primary Key Gotcha
- From: Paul Lynch <email@hidden>
- Date: Fri, 20 Oct 2006 23:45:58 +0100
On 20 Oct 2006, at 17:57, Robert Walker wrote:
Oh I see. I misunderstood the issue slightly. You are saying that
EOF accepts user provided PK's as long as the value is > 1.0.
Gotcha. ;-)
Sounds like time to file a bug report on that one then.
Yes, but how to get past having to admit that I actually have a table
with a float primary key? :-)
On Oct 20, 2006, at 10:36 AM, Paul Lynch wrote:
That's not entirely true. We have the convention of using integer
or binary keys, sure. But, in a relational database, any type is
permitted for use as a primary key, and WebObjects should support
this, even if it can't generate a value. One of the primary key
generation mechanisms that is supported is for the user to supply
a value - if you really insist on having a string primary key, for
instance, then this is the only reasonable approach to take.
So this was exactly that "custom primary key generation scheme" -
I was trying to supply the value, and EO overrides it when the
float value is < 1.
I remember being disappointed way back when EOF stopped permitting
zeros in primary key fields, as it started to make the "primary
key" concept more of a private WebObjects concept rather than a
generic relational concept. They sneaked that in around EOF 2.2,
as I recall, and didn't even have the decency to wait for a major
release for such a substantial change.
Paul
On 20 Oct 2006, at 14:42, Robert Walker wrote:
Interesting, but unexpected behavior is exactly what I would
expect in this situation. EOF expects one of a couple different
data types for use as primary keys. Any type of float value
(including BigDecimal) is not one of them. Basically either a
unary integer PK or a specific binary format is what EOF can deal
with. Anything else requires some form of custom PK generation
scheme.
On Oct 19, 2006, at 3:09 PM, Paul Lynch wrote:
I just came across this, and thought the list might be interested:
I was just working with a legacy database which has a table with
a single column, which is of course designated as the primary
key. It happens to be a float, represented as a BigDecimal.
The (somewhat dubious) logic behind this design isn't important.
If I add a record to the table (EOGenericRecord), with the key
field set to a number greater than 1.0, everything is fine.
However, if I add a record with a value between 0 and 1.0 (which
is the vast majority of the records required), WO silently
replaces the value with the next available value from EO_PK_TABLE.
The reason behind this is that EO expects a primary key, when
supplied by the user, to be non-null and non-zero. It is
obviously (and mistakenly) assuming that values less than 1 are
equal to zero - probably because some programmer in the past
thought that no one would be dumb enough to use a float as a
primary key :-).
Incidentally, the above is what happens using OpenBase; the
MySQL driver just generates an exception claiming it is unable
to generate a primary key.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden