juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Faath" <jfa...@apache.org>
Subject RE: UDDI v3 persistence
Date Fri, 12 Dec 2008 17:24:03 GMT
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:kurt.stam@gmail.com] 
Sent: Friday, December 12, 2008 7:47 AM
To: juddi-dev@ws.apache.org
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 ;).


View raw message