Those objects will actually remain the same, the are the actual single
valued PKs. So I think this will work well.
Jeff Faath wrote:
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
