Xapian discuss - Jan 2009 - Query with version-numbers won't allow pages with Omega

Hello list,

A user discovered that searching for a query like 'counter strike 1.6' 
it is impossible to navigate to any but the first page in the search 
results.

We mimic the original 'query'-template behaviour with omega, by 
supplying the 'xDB', 'xP' and 'xFILTERS'-parameters back
to omega once a
search has been done. And my guess is that omega somehow misses the fact 
that the '1.6' in this case is actually already in the xP (which is 
something like Zcounter.Zstrik.1.6.), with strings with a '.' in between
it does work (paging with "counter.strike 1 6" works just fine).

It seems that the version-number is the culprit here.

We still use Xapian/Omega 1.0.5 and its not really trivial to just 
update to a newer version to see if such a small bug is fixed, but I 
didn't see any change in the changelog that suggests this issue being 
fixed with any of the newer versions?
If not, I'll report it to trac.

Best regards,

Arjen

On Wed, Jan 07, 2009 at 07:25:55PM +0100, Arjen van der Meijden
wrote:
> A user discovered that searching for a query like 'counter strike
1.6'
> it is impossible to navigate to any but the first page in the search 
> results.
> 
> We mimic the original 'query'-template behaviour with omega, by 
> supplying the 'xDB', 'xP' and 'xFILTERS'-parameters
back to omega once a
> search has been done. And my guess is that omega somehow misses the fact 
> that the '1.6' in this case is actually already in the xP (which is
> something like Zcounter.Zstrik.1.6.), with strings with a '.' in
between
> it does work (paging with "counter.strike 1 6" works just fine).
Here's the relevant bit of the code from Omega's query.cc:

    // Long, long ago we used "word1#word2#" (with trailing #) but
some broken
    // old browsers (versions of MSIE) don't quote # in form GET submissions
    // and everything after the # gets interpreted as an anchor.  We now allow
    // terms like `c#' so we want to avoid '#' anyway.
    //
    // So we switched to using "word1.word2." but that doesn't
work if
    // the terms contain "." themselves (e.g.
Tapplication/vnd.ms-excel)
    // so now we use "word1\tword2" instead (with no trailing
separator).
    //
    // However for compatibility with templates which haven't been updated
and
    // bookmarked queries from Omega 0.9.6 and earlier we still support
".".
    char separator = '\t';
    unsigned int n_old_terms = count(oldp.begin(), oldp.end(), '\t') +
1;
    if (n_old_terms == 1 && oldp[oldp.size() - 1] == '.') {
        separator = '.';
        n_old_terms = count(oldp.begin(), oldp.end(), '.');
    }

So the issue is really in your code which currently mimics the behaviour of a
query template from Omega 0.9.6 or earlier and which needs updating to fix
your bug.

If you change that to use a tab instead of a . like the current templates/query
then this will work correctly (since for multiple terms we'll find at least
one
tab and so (n_old_terms > 1) while for a single term xP isn't likely to
end in
a '.' - it certainly never will for TermGenerator generated terms).

I'm not sure if/when we should drop this compatibility code - it seems a
shame
to break bookmarked queries needlessly, especially as any non-updated templates
will still be generating the old style xP even though 0.9.7 changed the default
template back in October 2006.

Cheers,
    Olly