Solr Cell support

[GoogleCodeExporter]

Solr Cell does not appear to be supported.  I have attached a patch which
provides basic support, but it could do with some improvements
(specifically, it should allow an Apache_Solr_Document to be passed in, and
the URL should be built from that).

This patch is against the source from SolrPhpClient.r22.2009-11-09.tgz

Original issue reported on code.google.com by liam.obo...@gmail.com on 19 Feb 2010 at 5:38

Attachments:

• SPC_Solr_Cell.patch

[GoogleCodeExporter]

Hello,
How to use this function ?
Thanks
Franck.

Original comment by pixell...@gmail.com on 23 Apr 2010 at 10:19

[GoogleCodeExporter]

Hi Franck,

The patch needs to be applied against the current source.  Download the source 
from
the downloads page, download the patch and apply it using the patch command, 
i.e.

tar xzf SolrPhpClient.r22.2009-11-09.tgz
cd SolrPhpClient
patch -p1 < ../SPC_Solr_Cell.patch

You can then use the Apache_Solr_Service::extract() function to extract content 
using
Solr Cell.  You will need to provide the other parameters as a URL and the path 
to
the file to the extract function.

Original comment by liam.obo...@gmail.com on 23 Apr 2010 at 10:39

[GoogleCodeExporter]

I've committed an implemenation for this based on your original patch in r34. 
Note that I changed the 
signature to match more closely to other methods that take parameters 
(primarily search). I also added the 
ability to take a document instance for simpler management of field literals 
and boosts.

I had some issues with getting the parameter values in the multipart/form-data 
post body as they should be. 
So I went with the simplest implementation that works for now (parameters go in 
query string, post body is 
binary file content). 

Please let me know if this meets your usage.

Original comment by donovan....@gmail.com on 24 Apr 2010 at 12:50

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi Donovan,

Looks great, thanks, should work fine.  I'll integrate it with our application 
when I
get some time.

Liam

Original comment by liam.obo...@gmail.com on 2 May 2010 at 10:16

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Take a look at the extraction handler documentation again: 
http://wiki.apache.org/solr/ExtractingRequestHandler

All extra document fields need to be prefixed with "literal."  Also, you'll 
always (just like with regular 
documents) need to provide a document id (whatever you've configured in your 
solr schema configuration 
file). So if your id field is "id" you need to pass a field named "literal.id" 
to the extraction handler. The 
extraction handler is basically namespacing your extra document fields so that 
they don't interfere with its 
named parameters.  

Of note, the extract function also optionally takes an Apache_Solr_Document 
instance with fields, these fields 
will automatically be "namespaced" by the "literal." prefix for you as a 
convenience.

Finally, these types of question are better suited for the google discussion 
group I've set up. Please use that.

Original comment by donovan....@gmail.com on 11 May 2010 at 2:39

[GoogleCodeExporter]

Hello,
It work fine .. Very good job!
Is it possible to see the content field ? it 's searchable 
but not stored .
Tahnks

Original comment by pixell...@gmail.com on 11 May 2010 at 3:00

[GoogleCodeExporter]

whether a field is stored is controlled by the solr schema.xml configuration 
file

See http://wiki.apache.org/solr/SchemaXml#Common_field_options

Original comment by donovan....@gmail.com on 11 May 2010 at 3:08

[GoogleCodeExporter]

Sorry for the extremely slow feedback here!  I have integrated your updates and 
it works great, thanks, aside from the trivial issue I have raised (with a 
patch) in issue 47.

Original comment by liam.obo...@gmail.com on 6 Sep 2010 at 2:59