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 Sat, 13 Dec 2008 04:05:54 GMT
Yeah I just finished a first pass. I need to finish up some details 
tomorrow and add some tests to make sure it all works.

--K

Jeff Faath wrote:
>
> Sounds good to me then. I don’t foresee your changes causing any 
> issues other than the fact that I want to hold off on further 
> development until you finish so as not to have to redo anything. 
> Hopefully you’re close to completion?
>
> *From:* Kurt T Stam [mailto:kurt.stam@gmail.com]
> *Sent:* Friday, December 12, 2008 5:08 PM
> *To:* juddi-dev@ws.apache.org
> *Subject:* Re: UDDI v3 persistence
>
> 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:kurt.stam@gmail.com] 
> Sent: Friday, December 12, 2008 4:14 PM
> To: juddi-dev@ws.apache.org <mailto:juddi-dev@ws.apache.org>
> 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:kurt.stam@gmail.com] 
>
>     Sent: Friday, December 12, 2008 7:47 AM
>
>     To: juddi-dev@ws.apache.org <mailto: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