[OPEN-ILS-DEV] ***SPAM*** RE: Boolean Search Feature Questions
Mike Rylander
mrylander at gmail.com
Tue Apr 1 09:47:51 EDT 2014
On Mon, Mar 31, 2014 at 6:02 PM, Dan Reuther <
dReuther at catalystitservices.com> wrote:
> Mike,
>
>
>
> First, I realize the code on line 83 was not touched by you, I just
> included that since it was the line that was throwing the error, the error
> only throws after the patch is included though.
>
>
I understand. I was expressing my (mild) surprise and explaining that it
was unexpected, and why.
>
>
> As to how I installed the patch, I simply copied the added lines to the
> appropriate files in the perl/OpenSRF directory and commented out the
> deleted lines. As to the reason I restarted Evergreen, that was simply
> because I have a script that rebuilds it and stops and restarts OpenSRF
> etc. Just a shot gun approach. I have since applied the patch and
> restarted OpenSRF by its self and it fails to start with the patch code in
> place.
>
>
>
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.
> As near as I can tell $self->session is undefined in the return
> statement that creates the new AppSubrequest.
>
>
>
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.
A broader point, for which I'd like input from as many as would care to
look at it, is that while I'm certain we can make things work the way my
WIP code is heading, I wonder if it would simply be better to make a rule
for method_lookup() stating that if it is called as a class method it
returns a bare, blessed coderef (pre-patch behavior), but if called as an
instance method it returns a subrequest object (post-patch behavior). The
reasoning behind that is that when called as a class method you are either
doing something outside of a session context (as is the case with
O::Application::handler -- the session is separate from the method and only
then are they joined into a request object), or you don't care about the
session and are performing some utility function (such as in
direct_loader.pl, or the filtered metarecord constituent lookup in
O::A::Circ::Holds. In every instance-method case I could find in both the
OpenSRF and Evergreen code bases, the very next thing you do with the
method is call run(). So, I think the rule I outline above is already in
force for all practical purposes, and it would point to a simpler
implementation overall, IMO. In the least it would remove the need to
unwrap the subrequest in handler() as the attached patch does.
Thoughts, anyone?
--
Mike Rylander
| Director of Research and Development
| Equinox Software, Inc. / Your Library's Guide to Open Source
| phone: 1-877-OPEN-ILS (673-6457)
| email: miker at esilibrary.com
| web: http://www.esilibrary.com
> I do appreciate you taking the time to look at this, I am not trying to
> be difficult. I just have very little experience with this code base at
> this point and have actually never had the need to dive into the OpenSRF
> portion.
>
>
>
> Thanks
>
>
>
>
>
> *From:* open-ils-dev-bounces at list.georgialibraries.org [mailto:
> open-ils-dev-bounces at list.georgialibraries.org] *On Behalf Of *Mike
> Rylander
> *Sent:* Monday, March 31, 2014 1:14 PM
>
> *To:* Evergreen Development Discussion List
> *Subject:* Re: [OPEN-ILS-DEV] ***SPAM*** RE: Boolean Search Feature
> Questions
>
>
>
> Dan,
>
>
>
> While I can't definitively discount the possibility that the patch
> (which, as I mentioned, is untested) might be involved, the code reported
> in the error was not something I touched. Specifically, the session() sub
> containing line 83 of Application.pm is separate from the AppSubrequest
> class altogether, which has its own session() sub.
>
>
>
> You asked before about the OpenSRF version, so I wonder what, exactly, you
> did to install the patch and why you felt you needed to rebuild Evergreen
> -- it should have been a simple change to two files already installed on
> the system.
>
>
>
>
>
> On Mon, Mar 31, 2014 at 3:47 PM, Dan Reuther <
> dReuther at catalystitservices.com> wrote:
>
> Mike,
>
>
>
> Sorry to keep bugging you. I tried the patch out and I get the following
> errors when I restart OpenSRF and rebuild Evergreen.
>
>
>
> Updating fieldmapper
>
> Exception: OpenSRF::DomainObject::oilsServerError 2014-03-31T12:27:01
> OpenILS::Utils::Cronscript
> /usr/local/share/perl/5.14.2/OpenILS/Utils/Cronscript.pm:276 <500>
> Internal Server Error
>
> Can't use string ("OpenSRF::Application::Settings") as a HASH ref while
> "strict refs" in use at /usr/local/share/perl/5.14.2/OpenSRF/Application.pm
> line 83.
>
>
>
> -> /openils/var/web/opac/common/js//fmall.js
>
> Updating web_fieldmapper
>
> Exception: OpenSRF::DomainObject::oilsServerError 2014-03-31T12:27:01
> OpenILS::Utils::Cronscript
> /usr/local/share/perl/5.14.2/OpenILS/Utils/Cronscript.pm:276 <500>
> Internal Server Error
>
> Can't use string ("OpenSRF::Application::Settings") as a HASH ref while
> "strict refs" in use at /usr/local/share/perl/5.14.2/OpenSRF/Application.pm
> line 83.
>
>
>
> -> /openils/var/web/opac/common/js//fmcore.js
>
> Updating OrgTree
>
> Exception: OpenSRF::DomainObject::oilsServerError 2014-03-31T12:27:02
> OpenILS::Utils::Cronscript
> /usr/local/share/perl/5.14.2/OpenILS/Utils/Cronscript.pm:276 <500>
> Internal Server Error
>
> Can't use string ("OpenSRF::Application::Settings") as a HASH ref while
> "strict refs" in use at /usr/local/share/perl/5.14.2/OpenSRF/Application.pm
> line 83.
>
>
>
> This is the code from Application.pm
>
>
>
> sub session {
>
> my $self = shift;
>
> my $session = shift;
>
>
>
> if($session) {
>
> $self->{session} = $session;
>
> }
>
> #line 83-à return $self->{session};
>
> }
>
>
>
> I am trying to follow the ins and outs of OpenSRF but I figured I would
> run it by you.
>
>
>
> *From:* open-ils-dev-bounces at list.georgialibraries.org [mailto:
> open-ils-dev-bounces at list.georgialibraries.org] *On Behalf Of *Mike
> Rylander
> *Sent:* Monday, March 31, 2014 10:32 AM
>
>
> *To:* Evergreen Development Discussion List
>
> *Subject:* Re: [OPEN-ILS-DEV] ***SPAM*** RE: Boolean Search Feature
> Questions
>
>
>
> Dan,
>
>
>
> I wrote it in a clone of the master branch, but it will apply (perhaps
> with fuzz) to pretty much any version ... the code being touched is ancient.
>
>
> --
> Mike Rylander
> | Director of Research and Development
> | Equinox Software, Inc. / Your Library's Guide to Open Source
> | phone: 1-877-OPEN-ILS (673-6457)
> | email: miker at esilibrary.com
> | web: http://www.esilibrary.com
>
>
>
> On Mon, Mar 31, 2014 at 12:50 PM, Dan Reuther <
> dReuther at catalystitservices.com> wrote:
>
> Mike,
>
>
>
> What version of openSRF did you write this patch for? I currently have
> 2.2.0. Do I need to upgrade or do you see an issue with the version I have?
>
>
>
> Thanks
>
>
>
>
>
> *From:* open-ils-dev-bounces at list.georgialibraries.org [mailto:
> open-ils-dev-bounces at list.georgialibraries.org] *On Behalf Of *Mike
> Rylander
> *Sent:* Tuesday, March 25, 2014 2:08 PM
> *To:* Evergreen Development Discussion List
> *Subject:* Re: [OPEN-ILS-DEV] ***SPAM*** Boolean Search Feature Questions
>
>
>
> Dan,
>
>
>
> The code you mention isn't involved (it's not dealing with the layer that
> knows about the client-selected locale, and that comment is referring to
> the disconnect between MARC-prescribed language codes and
> everyone-else-in-the-world locale codes), but I think I see the issue. The
> short version is that method_lookup() in OpenSRF does not return an object
> that knows about the current session, which is needed to find the locale,
> thus the locale is forgotten at that point in the process. Attached is an
> OpenSRF patch for you try out ... note that it is entirely untested, but it
> should be something in the right direction. The point of it is to create
> the OpenSRF::AppSubrequest shim earlier, and stash the session there for
> use in the eventual call to run().
>
>
>
> If that works out for you I'll create a launchpad bug and post a
> pullrequest branch. OpenSRF 2.4 is planned for Soon(tm).
>
>
>
>
>
>
>
> On Tue, Mar 25, 2014 at 1:35 PM, Dan Reuther <
> dReuther at catalystitservices.com> wrote:
>
> This question is in regards to
> https://bugs.launchpad.net/evergreen/+bug/1152863
>
>
>
> I am tracking a bug in this implementation and could use some assistance.
> The feature seems to work as expected for English language searches. The
> problem is when we switch to say French Canadian the operators are not
> translated. I admit to not fully understanding how the localization system
> works in Evergreen. Does Evergreen currently have the ability to translate
> search queries?
>
>
>
> The behavior I am expecting is the following. Language is set to en-US
> and the user enters book or moon on the Boolean search tab and they
> are given the results that match book and the results that match moon.
> If the language is set to fr-CA and the user enters book ou moon
> they should see the same results. Currently the first works as
> expected the second returns no matches.
>
>
>
> I set the language to French (Canada) and then trace the locale through
> the program. I find that it switches to en-US in
> Application::Search::Biblio::multiclass_query.
>
>
>
> At line 950 in OpenILS/Application/Search/Biblio.pm I find the following
> comments
>
>
>
> # XXX This stops the session locale from doing the right thing.
>
> # XXX Revisit this and have it translate to a lang instead
> of a locale.
>
> #$arghash->{preferred_language} =
> $U->get_org_locale($arghash->{org_unit})
>
> # unless $arghash->{preferred_language};
>
>
>
> So I am curious if this is a known bug or just an unimplemented feature in
> Evergreen at this time and I am chasing a bug for functionality that does
> not exist?
>
>
>
> Any help would be appreciated. Thanks
>
>
>
>
>
> Dan Reuther
>
> Developer
>
> [image: Catalyst Logo]
>
>
>
>
>
>
>
> --
> Mike Rylander
> | Director of Research and Development
> | Equinox Software, Inc. / Your Library's Guide to Open Source
> | phone: 1-877-OPEN-ILS (673-6457)
> | email: miker at esilibrary.com
> | web: http://www.esilibrary.com
>
>
>
>
>
>
>
>
>
> --
> Mike Rylander
> | Director of Research and Development
> | Equinox Software, Inc. / Your Library's Guide to Open Source
> | phone: 1-877-OPEN-ILS (673-6457)
> | email: miker at esilibrary.com
> | web: http://www.esilibrary.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140401/3da71da1/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 11795 bytes
Desc: not available
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140401/3da71da1/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subrequest-with-session.2.patch
Type: text/x-patch
Size: 2019 bytes
Desc: not available
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140401/3da71da1/attachment-0001.bin>
More information about the Open-ils-dev
mailing list