juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kurt T Stam <kurt.s...@gmail.com>
Subject Re: UDDI v3 persistence
Date Fri, 12 Dec 2008 22:13:37 GMT
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: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
>
>
>   


Mime
View raw message