A couple of people wrote to suggest that I could use a database
context delegate to force acceptance of a float PK. Somewhat to my
surprise, it worked - I ran a test using Pierre's example code, more
or less. I was expecting EO to use the same check to see if returned
PKs are
Hi!
My guess is that someone tested for zero value using number.intValue
() == 0. This of course does rounding first and only then compares to
0. The correct way of doing things would have been to use a compare()
method. Guess that's worth a bug report.
I believe you can work around the
Paul,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
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
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
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
On Oct 20, 2006, at 3:45 PM, Paul Lynch wrote:
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
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
