Seems reasonable and I believe it's considered better form to use a "surrogate key" as the primary key as opposed to using a field (or fields) that has business meaning. Obviously, the entity key columns in the main entity tables should be made non-nullable and unique.
This will require cosmetic yet wholesale changes to the querying and mapping components. How soon can you get this done? I'd like to make these changes as soon as possible so as not to cause any delays. -Jeff -----Original Message----- From: Kurt T Stam [mailto:[email protected]] Sent: Friday, December 12, 2008 7:47 AM To: [email protected] Subject: UDDI v3 persistence Hi guys, I'm halfway into removing all the *Id.java classes from the persistence layer on the UDDI v3 branch, and it is making it all a lot cleaner. The reason they are there is b/c the way the PKs are setup in the UDDI v2 schema. They are composite PK, however we can simplify the PKs to be of type Long. Does anyone see any issues with this? Where we planning on using the parents business keys for fast searching or something? Are we afraid of running out of 'integers' in the ID columns? Speak up or hold your peace forever ;). --Kurt
