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: [email protected]
[mailto:[email protected]] 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: [email protected]<mailto:[email protected]>
| web: http://www.esilibrary.com<http://www.esilibrary.com/>
On Mon, Mar 31, 2014 at 12:50 PM, Dan Reuther
<[email protected]<mailto:[email protected]>> 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:
[email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>]
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
<[email protected]<mailto:[email protected]>> 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
[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: [email protected]<mailto:[email protected]>
| web: http://www.esilibrary.com
<<inline: image001.png>>
