Convert back to old-school ExtUtils::MakeMaker.

I reported an issue I encountered with utf8 on rt.cpan about 6 weeks ago. While my bug report will not be particularly helpful in tracking down the bug I did provide an example of a workaround that I was able to use to get passed the problem. I'm reposting the issue in this forum because it appears the maintainers are more active here.

rtcpan 89288
I'm using webservice::solr as a catalyst model (extending catalyst::model rather than using the dedicated adapter). catalyst is 5.90042. OS is mint 15 (ubuntu 13.04) x64. solr instance is 4.4 and the data comes from postgres, both the collection and source data are configured as utf8. I have a long text field in my solr database, which when rendered by the view results in the following error and no data returned to the client browser. [error] Caught exception in engine "Wide character in syswrite at /usr/lib/perl/5.14/IO/Handle.pm line 216, line 1003." I'm attaching a text file giving an example of the raw text. As a workaround I wrote a macro in template toolkit: [% MACRO utfclean(field) PERL %] use utf8; my $field = $stash->get('field'); utf8::encode($field); print $field ; [% END %] [% utfclean( doc.value_for('description') ) %]

For example:

my %args = ( q => 'cows' );
my $q = WebService::Solr::Query->new( \%args );
$q->localparams( '{!tag=foo}' );
say $q->stringify;

prints

{!tag=foo}(q:"cows")

See https://solr.apache.org/guide/8_9/local-parameters-in-queries.html for more about local parameters.

See also https://rt.cpan.org/Public/Bug/Display.html?id=114415

use Carp::Always;
use WebService::Solr::Query;

my $q = WebService::Solr::Query->new( { title => [ -and => { -prohibit => 'star' }, { -prohibit => 'wars' } ] } );

my $scalar = $q->stringify;
print "Scalar: $scalar\n";

my @array = $q->stringify;
print "Array:  $array[0]\n";

my $stringy = "$q";
print "String: $stringy\n";

Run this and you get:

Scalar: (((-title:"star") AND (-title:"wars")))
Not a SCALAR reference at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 148.
        WebService::Solr::Query::_value_SCALAR('WebService::Solr::Query=HASH(0x7af9de8)', 'title', 'HASH(0x6f94238)') called at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 187
        WebService::Solr::Query::_value_ARRAY('WebService::Solr::Query=HASH(0x7af9de8)', 'title', 'ARRAY(0x702efb8)') called at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 137
        WebService::Solr::Query::_dispatch_value('WebService::Solr::Query=HASH(0x7af9de8)', 'title', 'ARRAY(0x702efb8)') called at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 64
        WebService::Solr::Query::_struct_HASH('WebService::Solr::Query=HASH(0x7af9de8)', 'HASH(0x7af9fe0)') called at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 37
        WebService::Solr::Query::_dispatch_struct('WebService::Solr::Query=HASH(0x7af9de8)', 'HASH(0x7af9fe0)') called at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 78
        WebService::Solr::Query::_struct_ARRAY('WebService::Solr::Query=HASH(0x7af9de8)', 'ARRAY(0x7ac5728)') called at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 37
        WebService::Solr::Query::_dispatch_struct('WebService::Solr::Query=HASH(0x7af9de8)', 'ARRAY(0x7ac5728)') called at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 27
        WebService::Solr::Query::stringify('WebService::Solr::Query=HASH(0x7af9de8)') called at foo.pl line 9

Calling the overloaded version with my $stringy="$q" (by commenting out the two array lines) blows up the same way.

Scalar: (((-title:"star") AND (-title:"wars")))
Not a SCALAR reference at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 148.
        WebService::Solr::Query::_value_SCALAR('WebService::Solr::Query=HASH(0x11f43f70)', 'title', 'HASH(0x11ea9238)') called at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 187
        WebService::Solr::Query::_value_ARRAY('WebService::Solr::Query=HASH(0x11f43f70)', 'title', 'ARRAY(0x1298b818)') called at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 137
        WebService::Solr::Query::_dispatch_value('WebService::Solr::Query=HASH(0x11f43f70)', 'title', 'ARRAY(0x1298b818)') called at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 64
        WebService::Solr::Query::_struct_HASH('WebService::Solr::Query=HASH(0x11f43f70)', 'HASH(0x11f43dc0)') called at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 37
        WebService::Solr::Query::_dispatch_struct('WebService::Solr::Query=HASH(0x11f43f70)', 'HASH(0x11f43dc0)') called at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 78
        WebService::Solr::Query::_struct_ARRAY('WebService::Solr::Query=HASH(0x11f43f70)', 'ARRAY(0x129da708)') called at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 37
        WebService::Solr::Query::_dispatch_struct('WebService::Solr::Query=HASH(0x11f43f70)', 'ARRAY(0x129da708)') called at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 27
        WebService::Solr::Query::stringify('WebService::Solr::Query=HASH(0x11f43f70)', undef, '') called at foo.pl line 12

Note that these are running against installed WebService::Solr, but they fail the same way with -Mblib against the version in Git.

At the very least, a pointer to http://wiki.apache.org/solr/SimpleFacetParameters would help.

Hello.

Are you open to merging this change set: dev...amaltsev:webservice-solr:dev

It adds a way to retrieve grouped documents. Originally implemented by Matt on https://github.com/imjinn/webservice-solr and I merged your 0.44 changes and fixed test cases to work.

If you prefer to do it differently I can modify the change in some way.

It's been used in production for a couple of years. But I'd rather install from cpan than from a local repo.

Thanks!

SolrJ lets you set the request handler used for a particular query, if you need to use something besides /select. WebService::Solr does not.

http://lucene.apache.org/solr/4_8_0/solr-solrj/org/apache/solr/client/solrj/SolrQuery.html#setRequestHandler%28java.lang.String%29

In Solr versions before 3.6, the handleSelect parameter was set to "true" in the example config. This meant that you could send a "qt" parameter to change the handler being used.

Since 3.6, this way of configuring Solr is deprecated. All handlers are now expected to have names starting with a forward slash, which makes it possible to use them in the actual URL. A handler named "/select" will normally exist in a typical solrconfig.xml file. The big reason this change was made is so that you can't send a request to /select, set the qt parameter to "/update", and therefore change the index even when normal access to the /update handler is somehow blocked.

In the current code for this project, "/select" is not a single string. The forward slash is separate. In solrconfig.xml they are together. To match user expectations, this feature needs to work if "/other" (including the foward slash) is sent in as the handler name. If you want to include magic so that simply sending "other" will also work, that's fine.

Get the status JSON from the Solr instance at admin/cores?action=STATUS&wt=json and return a hash of the deserialized JSON.

I couldn't find anything in the documentation specific to geospatial queries.

It wasn't hard to generate an appropriate string to pass to fq. I could easily turn my code into a method. Probably the most consistent thing would be to create a method in the Query submodule.

From @lukec in #16:

I have noticed the following warning from about $response->docs() being read-only. I suspect that in the dependency change, the docs field is going from implicit rw to ro.

The field is not declared ro/rw:

https://github.com/petdance/webservice-solr/blob/dev/lib/WebService/Solr/Response.pm#L24

But then a few lines below we use the setter method: https://github.com/petdance/webservice-solr/blob/dev/lib/WebService/Solr/Response.pm#L29

So in summary, I think docs should explicitly be listed as is => 'rw'.

search() modifies the $params sent to it. It should not do this.

sub search {
    my ( $self, $query, $params ) = @_;
    $params ||= {};
    $params->{ 'q' } = $query;
    return $self->generic_solr_request( 'select', $params );
}

Another user had opened an issue about querying for all documents. The question was actually answered in the documentation, looking at the code I saw that it was trivial to implement a specific method for that and would be convenient to users of the module to have.

Please accept or reject the patch I proposed on rt.cpan.

This can be as simple as cutting & pasting & modifying facet_fields.

As it is now, users can't get back facets for ranges or dates.

Calling Solr functions inside a Perl thread is resulting in exception because of JSON:XS module is not able to handle the responses correctly.

File: WebService/Solr/Response.pm
sub _build_content

Can we use a thread safe module for json parsing purposes ?
https://metacpan.org/pod/Cpanel::JSON::XS

I need to index a array field. I passed the reference. It complains that

The Field looks like the following 🎱
bless( {
'value' => [
'Dancing'
],
'name' => 'doc_pref_lookingfor_txt'
}, 'WebService::Solr::Field' ),

It complains saying that : invalid XML data: character data isn't a string

Please let me know how to index array.

Thanks
Arvind

WebService::Solr::Query starts with a big ol' use Data::Dumper at the top, which is unnecessary 99% of the time. Make it conditional.

Currently, W::S::Q lets you create a Solr query like this:

$ perl -MWebService::Solr::Query -le 'print WebService::Solr::Query->new( { foo => [ 'bar', 'baz' ] } );'
  ((foo:"bar" OR foo:"baz"))

However, you can't create sub-queries with this:

$ perl -MWebService::Solr::Query -le 'print WebService::Solr::Query->new( { foo => [ [ 'bar' ], [ 'baz' ] ] } );'
Not a SCALAR reference at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Solr/Query.pm line 149.

I'm interested in doing sub-queries because I want to get beyond Solr's maxBooleanClauses limit, since each sub-query is counted as 1 boolean query in Solr. By doing a query like ((foo:"a1" OR foo:"a1000") OR (foo:"b1" OR foo:"b1000") OR …) I can get many more things OR'd and still stay under the maxBooleanClauses limit.