[OPEN-ILS-DEV] ***SPAM*** RE: Boolean Search Feature Questions

[Dan Reuther]

I have a couple other issues I am encountering as well.  The first is that it seems which ever type of search I try first ends up being the default for all future searches.  For example if one searches for   book || moon   on the basic search tab that works correctly.  But then searching on the Boolean tab with   book or moon   will return incorrect results.   But   book || moon   works.   If you restart evergreen and try this in the reverse order you get the opposite result.  In short the first one tried works as intended and then the other one is broken.  I could use some guidance on this.  There is code to reset the operators and I have logged and tracked them and they seem to be changing as one would expect.  It looks to me like the parser operators is a singleton object?  Is that correct?

The second issue could be more serious.  Disregarding the first issue if you search on the Boolean tab with say   book or moon   it works correctly  but then   book || moon   does not.  This seems to be working as intended since the operators in the query parser are set to the English words and not symbols.   But the symbols should work as well.  Is there a way to overload the operators in the query parser?  From what I have looked at it seems one would have to add another set of plain language operators and then put or statements throughout the query parser to facilitate both operators, ie  or   and ||, working correctly.  The plain language operators would still need to be localized.

This brings the problem of now a basic search would also interpret plain language operators as Boolean and not words, unless a flag was passed into the parser to limit that behavior.  I get the feeling this is a decent sized change to the query parser and wonder if there is an easier way.  Could we not just use a reg ex in say query_parser_fts_wrapper in metabib.pm to convert the plain language operators to the symbols and then pass that into the parser.  We could do the localization at this point as well.

I know this is similar to the original way this feature was implemented and there was pushback against that so I want to get feedback and guidance on this before I set about implementing it.   It is entirely possible I am missing something trivial that fixes all of this.

Thanks


From: open-ils-dev-bounces at list.georgialibraries.org [mailto:open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of Dan Reuther
Sent: Tuesday, April 01, 2014 3:41 PM
To: Evergreen Development Discussion List
Subject: Re: [OPEN-ILS-DEV] ***SPAM*** RE: Boolean Search Feature Questions


I'm sorry if it sounded like I was questioning the need to restart services -- I wasn't.

Part of the reason that I and others have been nudging you toward the list is so that others can either jump in to help, or learn from our discussion.  I'll try to be more explicit.

With that in mind, I'm all for automating repetitive tasks, but I want to make sure that both you and anyone following along at home doesn't get the impression that a full rebuild would be necessary for this sort of change.  For testing out a WIP patch that just touches the Perl, simply dropping the patch in place and restarting services (and, if mod_perl code is touched, apache) is enough.

I also apologize if I came off as defensive, I appreciate any guidance you provide, I find it extremely valuable.

That's a symptom, yes.  The ultimate cause is that method_lookup() can be called as a class method, so the invocant $self is a package name instead of an instance, but session() assumes it is being called as an instance method.  The class method is a legitimate use case, so I've restructured the patch a little to account for that, and to try to make sure that calling code gets everything it needs by unwrapping the subrequest in one case.

I have tried out this latest patch and OpenSRF will start now but I am still not getting the locale to propagate as expected.   Looking in OpenILS/WWW/EGCatLoader/Search.pm


434<http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Search.pm;h=3a69fb1937402bc0f5eecde6f149cce7fec0d59d;hb=HEAD#l434>
 435<http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Search.pm;h=3a69fb1937402bc0f5eecde6f149cce7fec0d59d;hb=HEAD#l435>             my $method = 'open-ils.search.biblio.multiclass.query';
436<http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Search.pm;h=3a69fb1937402bc0f5eecde6f149cce7fec0d59d;hb=HEAD#l436>             $method .= '.staff' if $ctx->{is_staff};
437<http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Search.pm;h=3a69fb1937402bc0f5eecde6f149cce7fec0d59d;hb=HEAD#l437>             $method =~ s/biblio/metabib/ if $is_meta;
438<http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Search.pm;h=3a69fb1937402bc0f5eecde6f149cce7fec0d59d;hb=HEAD#l438>
 439<http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Search.pm;h=3a69fb1937402bc0f5eecde6f149cce7fec0d59d;hb=HEAD#l439>             my $ses = OpenSRF::AppSession->create('open-ils.search');
440<http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Search.pm;h=3a69fb1937402bc0f5eecde6f149cce7fec0d59d;hb=HEAD#l440>
 441<http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Search.pm;h=3a69fb1937402bc0f5eecde6f149cce7fec0d59d;hb=HEAD#l441>             $self->timelog("Firing off the multiclass query");
442<http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Search.pm;h=3a69fb1937402bc0f5eecde6f149cce7fec0d59d;hb=HEAD#l442>             my $req = $ses->request($method, $args, $query, 1);
443<http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Search.pm;h=3a69fb1937402bc0f5eecde6f149cce7fec0d59d;hb=HEAD#l443>             $results = $req->gather(1);
444<http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Search.pm;h=3a69fb1937402bc0f5eecde6f149cce7fec0d59d;hb=HEAD#l444>             $self->timelog("Returned from the multiclass query");

I believe the call to OpenSRF on line 439 is what kicks this whole process off.  $ctx->{locale} is correct at this point, reflecting the settings selected on the web interface.   $ses->{session_locale}  is always en_US regardless.  Looking at the call I notice that the locale is never passed into OpenSRF.  Does this have to happen here? On a whim I did try this .. $ses->{session_locale}  = $ctx->{locale}    This has the effect of having the correct language setting propagate down into metabib.  Of course this still does not fix the issue so I am continuing to look.

That brings the question, where is this translation supposed to happen?  In the Query Parser?  I have not been able to locate the code that handles this task.

I have also found another issue, which may or may not be related to this.