Anil, to ensure that Scout will work with any UDDI server you need to use the standard UDDI calls exclusively. Right?
Steve -----Original Message----- From: Anil Saldhana [mailto:[EMAIL PROTECTED] Sent: Monday, March 07, 2005 9:30 AM To: [email protected] Subject: RE: question about 'delete_business' Steve, another important Q from Scout. "I try to delete a business in jUDDI. But I get a foreign key violation in PUBLISHER_ASSERTION table. The reason is that there are pub assertions involving this business in this PUB_ASSERT table." What I need is a way to delete all the publisher assertions this Business is involved in, before I delete the business. Somehow uddi findPublisherAssertion(AuthInfo) seems limited for what I am trying to achieve. Is there any other hook provided by juddi? Cheers, Anil --- "Viens, Stephen" <[EMAIL PROTECTED]> wrote: > Anne, > > The last sentence of the v2 UDDI spec reads > > "The key that caused the error will be > clearly indicated in the error text." > > Does the term "error text" used here represent a > specific property in > the SOAP Fault or DispositionReport or is it meant > to be ambiguous and > implementation defined? > > Steve > > -----Original Message----- > From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] > Sent: Saturday, February 19, 2005 4:44 PM > To: [email protected] > Subject: Re: question about 'delete_business' > > > According to the UDDI v2 spec, the SOAP fault should > return the key that > was invalid: > > E_invalidKeyPassed: signifies that one of the > uuid_key values passed did > not match with any known businessKey values. No > partial results will be > returned - if any businessKey values passed are not > valid or if the > message contained multiple instances of a uuid_key > value, this error > will be returned. The key that caused the error > will be clearly > indicated in the error text. > > - Anne > > > On Fri, 11 Feb 2005 10:23:52 -0500, Geir Magnusson > Jr > <[EMAIL PROTECTED]> wrote: > > > > On Feb 11, 2005, at 10:08 AM, Anil Saldhana wrote: > > > > > Geir, > > > I had thought of the same a month back. > > > > > > I thing the right thing to do is call jUDDI n > times > > > for n keys to delete, because we have to keep > track of partial > > > commits. > > > > Right - OTOH, the JavaDoc says > > > > "partial commits are allowed" > > > > not required. I figure that we do want to try the > one-shot first, and > > > if that fails, then iterate through... I'll add > that as a JIRA in > > Scout-land. (Will give me a reason to go find > it...) > > > > geir > > > > > > > > Regards, > > > Anil > > > > > > > > > --- Geir Magnusson Jr <[EMAIL PROTECTED]> > wrote: > > > > > >> Additional thought... > > >> > > >> On Feb 11, 2005, at 6:58 AM, Geir Magnusson Jr. > > >> wrote: > > >>> > > >>> JAXR says that I can do a > deleteOrganizations() > > >> and have a partial > > >>> commit, stopping on the first failure. In my > > >> case, I assume that the > > >>> first good key will be deleted, and the second > > >> not. This seems then > > >>> that to use jUDDI (or any UDDI registry - I'm > not > > >> picking on jUDDI), I > > >>> must send two separate delete_business > messages? > > >> > > >> ... if I wish to perform partial commits? > seems > > >> like the performant > > >> thing to do is assume that this kind of failure > is > > >> rare, always try > > >> single-message multi-key deletes, returning a > JAXR BulkResponse to > > >> my callers w/ only one error in the event of a > failure, > > >> letting them > > >> assume that nothing worked? > > >> > > >> How does a UDDI user figure out which key is > bad > > >> since the UDDI > > >> response message doesn't give any hint of which > key > > >> was the bad one...? > > >> Seems like you then need to play > delete_business wack-a-mole... > > >> > > >> geir > > >> __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
