Mailing-List: contact juddi-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: juddi-dev@ws.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: "Jeff Faath" <jfaath@apache.org>
To: <juddi-dev@ws.apache.org>
References: <49426B5B.7020101@gmail.com>
In-Reply-To: <49426B5B.7020101@gmail.com>
Subject: RE: UDDI v3 persistence
Date: Fri, 12 Dec 2008 11:24:03 -0600
Message-ID: <002401c95c7e$6dedde70$49c99b50$@org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclcYDCsAQyAY3sOSAiCdP+Vfe1Y6gAHN84w
Content-Language: en-us

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 ;).

--Kurt