I switched the "i" to "l" in the value type of my primary key
prototype (strangely the "integer" menu changed to "Double", but Java
class is still "Number" so I'm not worried, specially because it
works!).
When I run the code again, the function from the wikibook did not
work, as expected. I switched everything to Longs, and it started
working again, so I suppose it's fine. It's not loosing info, because
it explicitly checks is the PK is an instanceof Long (or, previously,
Integer).
This was cool, as I thought I was working with 64-bit PKs, and
actually I was using only 32-bits...
Yours
Miguel Arroz
On 2007/03/20, at 18:55, Ray Kiddy wrote:
On Mar 20, 2007, at 11:17 AM, Miguel Arroz wrote:
Hi!
I'm in the state of panic here...
I have modeled my DB using 8 byte primary key values. Apparently
PostgreSQL takes this fine.
I started suspecting that it would not work, because it checks
for an Integer, and the key should be a Long value. The problem is
that... it worked!
What does this mean? WO only supports 4 byte primary keys?
That's not good at all... please tell me I'm going crazy for no
reason and there's something tremendously obvious that I have missed.
Yours
Miguel Arroz
It is probably working because the cast of the pk is losing data,
but the pk is still unique. But it also sounds as though you
already know not to rely on this behavior.
I had not looked at the wikibook documentation you refer to. For
what you are trying to do, you may want to look at the
databaseContextNewPrimaryKey method in the
EODatabaseContext.Delegate class.
- ray
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/arroz%
40guiamac.com
This email sent to email@hidden
"We have no sympathy for the lost souls
We've chosen the path of disgrace
We give this life to our children
And teach them to hate this place" -- Apocalyptica, Life Burns!
