Now that I think about it, it does cause an inconvenience although it seems slight right now (let's hope it stays that way). Anytime an entity is retrieved or deleted, I was able to use the entity key directly to work with the object. A lot of calls receive user input directly as keys (the delete_xxx methods, get_xxx methods, etc) and there are many instances where I have to check for the existence of an entity.
I guess now instead of using the entity key directly in entityManager calls, I'll have to run a query to find the real ID based on the entity key. I don't see this as being a big deal now, but there's a lot of functionality to re-work so I hope there are no snags. -----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
