[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] Re: [Meeting Minutes] RS Spec review special meeting1/25/2005
Farrukh Najmi wrote: > Diego Ballve wrote: > >> Farrukh Najmi wrote: >> >>> Farrukh Najmi wrote: >>> >>>> Diego Ballve wrote: >>>> >>>>> Farrukh Najmi wrote: >>>>> ... >>>>> >>>>>> * Diego: 9.2.2.2. Iterative federated query behavior not clear >>>>>> o Resolution: Agreed that intended behavior works fine. Diego >>>>>> to suggest revised text for Iterative federated query behavior >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ... >>>>> >>>>> >>>>> Changes are limited to the last paragraph: >>>>> >>>>> Current: >>>>> >>>>> "When a client submits a federated iterative query, the registry >>>>> MUST use the startIndex attribute value of the original request as >>>>> the startIndex attribute value of the routed request sent to each >>>>> federation member. In such cases the registry MUST return a >>>>> totalResultCount attribute value on the federated query response to >>>>> be equal to the maximum totalResultCount attribute value returned >>>>> by a routed query response from each federation member." >>>>> >>>>> Suggested: >>>>> >>>>> "When a client submits a federated iterative query, the registry >>>>> MUST use the startIndex attribute value of the original request as >>>>> the startIndex attribute value of the routed request sent to each >>>>> federation member. The response to the original request MUST be the >>>>> union of the results from each routed query. In such cases the >>>>> registry MUST return a totalResultCount attribute value on the >>>>> federated query response to be equal to the sum of totalResultCount >>>>> attribute values returned by each federation member." >>>>> >>>>> Regards, >>>>> Diego >>>>> >>>> +1. Fixed for draft 02. Thanks Diego! >>>> >>> Oops I sent my +1 too soon before careful reading... >>> >>> In the single registry iterative query case, the totalResultCount on >>> an AdhocQueryResponse is not the total # of results returned but the >>> number of results matched within the registry. >>> >>> For this reason in the federated iterative query case the >>> totalResultCount MUST be the MAX not SUM of all individual >>> totalResultCounts. >>> >>> I would rephrase your paragraph to: >>> >>> "When a client submits a federated iterative query, the registry MUST >>> use the startIndex attribute value of the original request as the >>> startIndex attribute value of the routed request sent to each >>> federation member. The response to the original request MUST be the >>> union of the results from each routed query. In such cases the >>> registry MUST return a totalResultCount attribute value on the >>> federated query response to be equal to the maximum of >>> totalResultCount attribute values returned by each federation member." >>> >>> >> >> Then I missed the point. You are saying that, for example: >> We query Reg A, federated with Reg B and Reg C. >> - Query matches 4 objects in Reg A >> - Query matches 5 objects in Reg B >> - Query matches 3 objects in Reg C, 2 of wich are replicas from A. >> >> totalResultCount = ? >> I though MAX would return "5" in this case. >> Plain SUM would be "12", but that is incorrect too. >> Best answer would be "10" >> >> Diego > > > The totalResultCount parameter would have been better called > totalMatchCount which is the number of objects matched in the target > registry. > > The point of this parameter is to allow client to dtermine how many > times to iterate over the iterative query (while (i < totalResultCount)) > As long as totalResultCount indicates there is more data to fetch the > client does another query iteration after bumping up the startIndex. > > So lets say the maxResults (how many most can be fetched in one > iteration) is 2 then this is how your example plays out (compare with > 6.2.1 in RS draft 01): > > Iteration 1: startIndex=0, maxResults=2, totalResultCount=5, # of results=2 > Iteration 2: startIndex=2, maxResults=2, totalResultCount=5, # of results=2 > Iteration 3: startIndex=4, maxResults=1, totalResultCount=5, # of results=1 > > Hope that it makes sense why we need MAX instead of SUM. This is > definitely a little hard to explain but > I hope I have it right. > Thanks for the long explanation, but we are talking about the same thing in 1 point: for the client it is the max number of results. What I meant by sum was SUM(MAX(Member1):MAX(MemberN)), from federation "router" point of view, not client, and in total, not per iteration. So in the end we would come to the same point. Diego -- Diego Ballve Digital Artefacts Europe http://www.digital-artefacts.fi
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]