2008/5/7 Jamie McCracken <[EMAIL PROTECTED]>: > > On Wed, 2008-05-07 at 16:29 +0200, Jos van den Oever wrote: > > 2008/5/7 Jamie McCracken <[EMAIL PROTECTED]>: > > > we need ranges in order to search efficiently - having potentially > > > random hit IDs passe to that function means we cannot optimise (no > way > > > to tell in advance if its a range) > > > > > > Its so bad that we will add an extension GetPagedHits ourselves if no > > > one else wants it! > > > > You're seeing ghosts. It's trivial and very quick to check if a range > > of numbers is sequential. > > If it's sequential, you can use your optimized range function, if not, > > get the hits one by one. For the later you need a function anyway. > > >
Jamie? Can you comment on Jos' answer? If you implement paged hit retrieval anyway, it would be a very cheap optimization to check if hit_ids are sequential in GetHitData and then take the optimized path. If it is not enough to simply change the documentation of GetHitData to imply that it is more advanced way to retrieve hits (and not mainly a tool to use on HitsModified), can you then be more specific about your needs (for the method)? I am thinking: * A use case - No app I know of will require the API you describe. Not even the native Tracker search tool (it can only scroll pages sequentially). Anywhere libbeagle is usable, so is Xesam, but with a more advanced interface. * Should it take an array of fields to retrieve, or use the hit.fields property like GetHits? If you want to take the fields as an arg I think it is earily close to GetHitdata, but if you want to use hit.fields, ie GetPagedHits(in s search, in u offset, in u count, out aav hits), then it makes more sense to me. Cheers, Mikkel
_______________________________________________ Xesam mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xesam
