No, I'm talking about getting the BusinessEntity by the business key. I was figuring you were going to create these Long id fields for the main entities but I could be wrong. Are the "entity keys" still the primary keys for the main entities?
-----Original Message----- From: Kurt T Stam [mailto:[email protected]] Sent: Friday, December 12, 2008 4:14 PM To: [email protected] Subject: Re: UDDI v3 persistence Are you talking about finding Addresses etc by using the BusinessEntity Key? Jeff Faath wrote: > 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 > > >
