Thanks for your inputs. However I still unable get to work. I tried both methods. Did it works for you? My search found 0 document when I multiple fqs.

# build an array of facets
my @fqs = ( ‘systype:LA’, ‘location:US’ );

# build the search options
my %search_options = ();
$search_options{ ‘start’ } = $start_record,
$search_options{ ‘rows’ } = $maximum_records;
$search_options{ ‘fq’ } = [ @fqs ];

# do the work; search
my $response = $solr->search( $query, \%search_options );

I had similar issues in my Alex Catalogue. Specifically, it is possible to enter a query, get a search result, and refine it through any number of facets (Solr fq values). To accommodate this functionality I wrote the following to build my Solr query:

# build the search options
my %search_options = ();
$search_options{ 'start' }          = $start;
$search_options{ 'rows' }           = ROWS;
$search_options{ 'facet' }          = 'true';
$search_options{ 'facet.field' }    = [ 'type', 'facet_creator', 'facet_subject', 'repository' ];
$search_options{ 'facet.mincount' } = MINCOUNT;
$search_options{ 'sort' }           = $sort;
if ( $cgi->param( 'fq' ) ) { $search_options{ 'fq' } = [ $cgi->param( 'fq') ] };

# do the work; search
my $response = $solr->search( $query, \%search_options );

Notice how $search_options{ ‘fq’ } points to a reference to an array. And notice later how the search method includes a reference to %search_options.

Maybe the following will work for you:

# build an array of facets
my @fqs = ( 'systype:LA', 'location:US' );

# build the search options
my %search_options         = ();
$search_options{ 'start' } = $start_record,
$search_options{ 'rows' }  = $maximum_records;
$search_options{ 'fq' }    = [ @fqs ];

# do the work; search
my $response = $solr->search( $query, \%search_options );

Good luck.

On my previous post, I forgot the put multiple fq. Basic I want to do multiple fq on webservice::solr. Is that possible? If so can you give me some advise.

my $response = $solr->search( $query, {
’start’ => $start_record,
‘rows’ => $maximum_records ,
‘fq’ => ’systype:LA’,
‘fq’ => ‘location:US’
});

This code failed.

I have problem with solr fq (facet query). If I use q=system&fq=systype:LA on SOLR admin page, it works.

I tried both of these methods using Webservice and it failed . Can you give some inputs to solve this problem.

Thanks

my $response = $solr->search( $query, {
‘start’ => $start_record,
‘rows’ => $maximum_records ,
‘fq’ => ‘systype:LA’
});

my $response = $solr->search( $query, {
‘start’ => $start_record,
‘rows’ => $maximum_records ,
‘facet.query’ => ‘systype’,
‘systype’ => LA
});

There has always been a bit of an elephant in the room with the issue of identifying schemas, from the “XML” and element set name wranglings of Z3950 to the advanced SRU “It’s just a URI (Lets hope naming the problem happens to solve it too)”

If the answer to these problems is “Just give everything a mime type” then thats cool (We certainly need some registry) but what should the mime type for mods actually look like?

I’ve been quite impressed with it. I think the idea of merging SRU into OpenSearch is a good one.

It’s not really true to say that “OpenSearch returns an RSS-like data stream” — rather an OpenSearch description can specify exactly what format is returned using a MIME type, and can even specify different URLs for retrieving different formats. So I think it’s rather compatible with SRU here. There’s no reason an OpenSearch description can’t declare results returned in MARC-XML or anything else. (I hope MARCXML, MODS, etc, have declared mime types? If not they need to asap for a billion reasons!)

Also, while an OpenSearch description document doesn’t declare any particular syntax for it’s query, there’s no reason an OpenSearch query _couldn’t_ be in CQL.

It would seem useful to me to extend OpenSearch to allow a description document to specify that CQL is supported, and specify what search indexes the server provides, or any other CQL-related metadata.

One of the most useful parts of OpenSearch is how it allows easy extensibility using custom namespaces. I am actually not that familiar with SRU, and haven’t read that OASIS document yet, but I hope they take the approach of trying to fit SRU into the existing OpenSearch standard, rather than creating a new ‘umbrella’ standard on top of it. I think the OpenSearch standard would be quite suited to this.

I perused the OpenSearch listserv recently, and I didn’t see any mention of OASIS or SRU. I hope the OASIS folks are actually talking to the OpenSearch folks about this, rather than just doing things in their own silo. The OpenSearch folks seem to me to be quite on top of things, and interested in making sure OpenSearch supports new use cases in the ‘right’ way.