| Paul,
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. 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.
|