Re: Motivation for white space after entities in HTMLStripReader
Hi. Let met do this -- I'll provide the first patch that: - addds entities which be written all in uppercase and are displayed correctly by browsers (amp, gt, lt, copy), - an optional argument that would prevent emitting additional spaces if these are not needed. Then I'll look at the CharFilter/CharStream and see what can be done about it. Dawid Yonik Seeley wrote: Perhaps the new CharFilter/CharStream stuff would work for this (i.e. HTMLStripReader modified to implement corrective offsets instead of inserting whitespace)? https://issues.apache.org/jira/browse/SOLR-822 -Yonik On Sat, Nov 22, 2008 at 4:31 AM, Dawid Weiss <[EMAIL PROTECTED]> wrote: Thanks Grant. You mean this issue: https://issues.apache.org/jira/browse/SOLR-42, I see now. This is a problem for me only, I guess, because I use HTMLStripReader independently of the Lucene architecture. This class is public, would it make sense if I provided a patch that would switch the whitespace emitting functionality on and off, depending on a particular person's use case? Dawid Grant Ingersoll wrote: It is an attempt at making things work properly with the highlighter (such that offsets are correct). I believe it works most of the time, but there still might be a few issues, check JIRA. -Grant On Nov 21, 2008, at 5:29 PM, Dawid Weiss wrote: Hi folks. What's the motivation to add exactly the number of white spaces after an entity declaration in HTMLStripReader? It basically looks like this: "lód" (UTF: lód, "ice" in Polish) is translated into: "ló d" This happens both with numeric entities and named entities. Needless to say, these added spaces in the character stream do no good as they effectively split a single term "lód" into two meaningless terms "l" and "d". I can fix this in the code easily, but it looks like it was intentional, so before I write test cases and commit a JIRA issue I would like to understand what the original reasons might have been (I really don't see anything this would be useful for). Apologies if I'm being dim here. Dawid -- Grant Ingersoll Lucene Helpful Hints: http://wiki.apache.org/lucene-java/BasicsOfPerformance http://wiki.apache.org/lucene-java/LuceneFAQ
[jira] Updated: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-725: --- Attachment: solr-725.patch updated for trunk 720487 > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Fix For: 1.3.1 > > Attachments: solr-725.patch, solr-725.patch, solr-725.patch, > solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *rename*: renames a core > h3. CoreAdminHandler: handles CoreContainer operations > * *load*/*create*: CoreContainer load > * *unload*: CoreContainer unload > * *reload*: CoreContainer reload > * *swap*: CoreContainer swap > * *alias*: CoreContainer alias > * *unalias*: CoreContainer unalias > * *rename*: CoreContainer rename > * *persist*: CoreContainer persist, writes the solr.xml > **stauts*: returns the status of all/one SolrCore -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-829) replication Compression
[ https://issues.apache.org/jira/browse/SOLR-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-829. Resolution: Fixed Fix Version/s: 1.4 Committed revision 720502. Thanks Simon, Noble, Hoss and Akshay! > replication Compression > --- > > Key: SOLR-829 > URL: https://issues.apache.org/jira/browse/SOLR-829 > Project: Solr > Issue Type: Improvement > Components: replication (java) >Reporter: Simon Collins >Assignee: Shalin Shekhar Mangar > Fix For: 1.4 > > Attachments: email discussion.txt, solr-829.patch, solr-829.patch, > solr-829.patch, solr-829.patch > > > From a discussion on the mailing list solr-user, it would be useful to have > an option to compress the files sent between servers for replication purposes. > Files sent across between indexes can be compressed by a large margin > allowing for easier replication between sites. > ...Noted by Noble Paul > we will use a gzip on both ends of the pipe . On the slave side you can say > true as an extra option to compress and send data from > server > Other thoughts on issue: > Do keep in mind that compression is a CPU intensive process so it is a trade > off between CPU utilization and network bandwidth. I have see cases where > compressing the data before a network transfer ended up being slower than > without compression because the cost of compression and un-compression was > more than the gain in network transfer. > Why invent something when compression is standard in HTTP? --wunder -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-856) Suport for "Accept-Encoding : gzip" in SolrDispatchFilter
[ https://issues.apache.org/jira/browse/SOLR-856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650575#action_12650575 ] Shalin Shekhar Mangar commented on SOLR-856: bq. If that's the consensus then i'm okay with that, but my personal preference would be to do it in a container agnostic manner (by explicitly using a Filter that does this in the stock web.xml) so that it works well for all users, regardless of container, out of the box. users who are knowledgeable about java, servlet containers, load balancers, etc... can then comment that filter out of the web.xml (or replace it with something else) I just committed SOLR-829 which makes it possible to use external compression (i.e. provided by containers) and also internal compression managed by ReplicationHandler itself. By default, compression is not used and it needs to be enabled explicitly on the slave's solconfig.xml so that the slave requests compression from the master. I feel that configuring internal compression is best configured through solrconfig.xml. Changing the web.xml after exploding the war is inconvenient. Also, compression logic is added directly to replication handler (for managing internal compression) because we do not need to compress other Solr responses. It is only the replication handler which needs this feature and that too only for replicating over slow connections (e.g. replicating across data centers). bq. So is this a "Won't Fix" situation? I think so. > Suport for "Accept-Encoding : gzip" in SolrDispatchFilter > - > > Key: SOLR-856 > URL: https://issues.apache.org/jira/browse/SOLR-856 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul > Attachments: SOLR-856.patch > > > If the client sends an Accept-Encoding : gzip header then SolrDispatchFilter > should respect that and send back data as zipped -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-876) Add ability to optionally splitOnNumerics WordDelimiterFilter/Factory
[ https://issues.apache.org/jira/browse/SOLR-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Rosher updated SOLR-876: Attachment: SOLR-876.patch Added in ability to 'protect' words against further tokenizing > Add ability to optionally splitOnNumerics WordDelimiterFilter/Factory > - > > Key: SOLR-876 > URL: https://issues.apache.org/jira/browse/SOLR-876 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Dan Rosher >Priority: Minor > Attachments: SOLR-876.patch, SOLR-876.patch > > > Add ability to optionally splitOnNumerics WordDelimiterFilter/Factory > Default behaviour is to splitOnNumerics as WordDelimiterFilter/Factory does > now > I was having issues with e.g. Java/J2SE becoming split into tokens 'Java','J' > '2' and 'SE' which isn't desired behavior in my instance, I wanted this to > be tokens 'Java', 'J2SE'. Another option I thought about but not implemented > was to have a protected list of words like solr.EnglishPorterFilterFactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solr nightly build failure
Sorry, my bad. I do remember running the tests but I think I forgot to check the results before adding the jars :) On Sun, Nov 23, 2008 at 10:19 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote: > On Sun, Nov 23, 2008 at 3:15 AM, wrote: > >[junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 0.439 sec > >[junit] Test org.apache.solr.core.ResourceLoaderTest FAILED > > This started happening after the latest Lucene upgrade. > Remember "ant clean test" is your friend ;-) > > -Yonik > -- Regards, Shalin Shekhar Mangar.
[jira] Created: (SOLR-881) Persistance error message and permissions
Persistance error message and permissions - Key: SOLR-881 URL: https://issues.apache.org/jira/browse/SOLR-881 Project: Solr Issue Type: Bug Affects Versions: 1.4 Environment: gentoo linux, tomcat, solr 1.4 Reporter: Jeff When you set peristant=true in the solr.xml for multicore it requires directory level write permissions. What it appears is that the whole file is replaced instead of edited. Additionally, if the permissions are not set it thows an IOException but doesn't explain why that is happening. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-284) Parsing Rich Document Types
[ https://issues.apache.org/jira/browse/SOLR-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650634#action_12650634 ] Grant Ingersoll commented on SOLR-284: -- bq. Tika doesn't need to do this explicitly you know all fields coming out of your call to the Tika API will be Tika fields. Solar Cell could map all Tika output fields to tika_* where * is the Tika outputted field name. And with field name mapping this default would be overridden, say tika_title mapped to "title". I can add in an option to have it do this mapping. > Parsing Rich Document Types > --- > > Key: SOLR-284 > URL: https://issues.apache.org/jira/browse/SOLR-284 > Project: Solr > Issue Type: New Feature > Components: update >Reporter: Eric Pugh >Assignee: Grant Ingersoll > Fix For: 1.4 > > Attachments: libs.zip, rich.patch, rich.patch, rich.patch, > rich.patch, rich.patch, rich.patch, rich.patch, SOLR-284.patch, > SOLR-284.patch, solr-word.pdf, source.zip, test-files.zip, test-files.zip, > test.zip, un-hardcode-id.diff > > > I have developed a RichDocumentRequestHandler based on the CSVRequestHandler > that supports streaming a PDF, Word, Powerpoint, Excel, or PDF document into > Solr. > There is a wiki page with information here: > http://wiki.apache.org/solr/UpdateRichDocuments > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-882) HTMLStripReader improvement - padding corrected for hexadecimal entities, option not to emit padding at all added
HTMLStripReader improvement - padding corrected for hexadecimal entities, option not to emit padding at all added - Key: SOLR-882 URL: https://issues.apache.org/jira/browse/SOLR-882 Project: Solr Issue Type: Improvement Reporter: Dawid Weiss Priority: Trivial Attachments: patch Improvements to HTMLStripHighlighter: - fix padding of hexadecimal entities (currently off by 1) - add an option not to emit padding at all. In certain applications padding emitted after entities such as ó may split words that are in fact single terms. - add entities that are recognized when written all in uppercase and recognized by browsers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-882) HTMLStripReader improvement - padding corrected for hexadecimal entities, option not to emit padding at all added
[ https://issues.apache.org/jira/browse/SOLR-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated SOLR-882: - Attachment: patch - Fixes hex. entities padding. - Adds a trigger to disable padding entirely. - Adds more tests to the test class. > HTMLStripReader improvement - padding corrected for hexadecimal entities, > option not to emit padding at all added > - > > Key: SOLR-882 > URL: https://issues.apache.org/jira/browse/SOLR-882 > Project: Solr > Issue Type: Improvement >Reporter: Dawid Weiss >Priority: Trivial > Attachments: patch > > > Improvements to HTMLStripHighlighter: > - fix padding of hexadecimal entities (currently off by 1) > - add an option not to emit padding at all. In certain applications padding > emitted after entities such as ó may split words that are in fact > single terms. > - add entities that are recognized when written all in uppercase and > recognized by browsers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Motivation for white space after entities in HTMLStripReader
Created an issue for this: https://issues.apache.org/jira/browse/SOLR-882 and added the patch that adds a trigger to disable padding and (!) fixes a bug in the current code -- hex. entities are not properly padded. Dawid Dawid Weiss wrote: Hi. Let met do this -- I'll provide the first patch that: - addds entities which be written all in uppercase and are displayed correctly by browsers (amp, gt, lt, copy), - an optional argument that would prevent emitting additional spaces if these are not needed. Then I'll look at the CharFilter/CharStream and see what can be done about it. Dawid Yonik Seeley wrote: Perhaps the new CharFilter/CharStream stuff would work for this (i.e. HTMLStripReader modified to implement corrective offsets instead of inserting whitespace)? https://issues.apache.org/jira/browse/SOLR-822 -Yonik On Sat, Nov 22, 2008 at 4:31 AM, Dawid Weiss <[EMAIL PROTECTED]> wrote: Thanks Grant. You mean this issue: https://issues.apache.org/jira/browse/SOLR-42, I see now. This is a problem for me only, I guess, because I use HTMLStripReader independently of the Lucene architecture. This class is public, would it make sense if I provided a patch that would switch the whitespace emitting functionality on and off, depending on a particular person's use case? Dawid Grant Ingersoll wrote: It is an attempt at making things work properly with the highlighter (such that offsets are correct). I believe it works most of the time, but there still might be a few issues, check JIRA. -Grant On Nov 21, 2008, at 5:29 PM, Dawid Weiss wrote: Hi folks. What's the motivation to add exactly the number of white spaces after an entity declaration in HTMLStripReader? It basically looks like this: "lód" (UTF: lód, "ice" in Polish) is translated into: "ló d" This happens both with numeric entities and named entities. Needless to say, these added spaces in the character stream do no good as they effectively split a single term "lód" into two meaningless terms "l" and "d". I can fix this in the code easily, but it looks like it was intentional, so before I write test cases and commit a JIRA issue I would like to understand what the original reasons might have been (I really don't see anything this would be useful for). Apologies if I'm being dim here. Dawid -- Grant Ingersoll Lucene Helpful Hints: http://wiki.apache.org/lucene-java/BasicsOfPerformance http://wiki.apache.org/lucene-java/LuceneFAQ
Re: Cleaning up a Few things
Yeah, -1 on Ant as a prerequisite, even though I use Ant to do this kind of stuff all the time. "java -jar start.jar" is pretty nice. On Nov 24, 2008, at 7:59 PM, Chris Hostetter wrote: : Or we could switch to using an ant task to start/run the examples. That would make ant a requirement for solr users, currently people who download the binary distributions don't need to know about ant at all. (i'm not saying we can't make it easy to pick confs with "ant run-example" but it needs to be easy with "java -jar start.jar" as well) -Hoss
[jira] Commented: (SOLR-875) Consolidate Solr's and Lucene's OpenBitSet classes
[ https://issues.apache.org/jira/browse/SOLR-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650756#action_12650756 ] Michael Busch commented on SOLR-875: I just committed and resolved LUCENE-1467. > Consolidate Solr's and Lucene's OpenBitSet classes > -- > > Key: SOLR-875 > URL: https://issues.apache.org/jira/browse/SOLR-875 > Project: Solr > Issue Type: Task >Reporter: Michael Busch >Priority: Minor > Attachments: solr-875.patch > > > Currently there are two versions of OpenBitSet and BitUtil in Solr and Lucene. > We should only have one version of these classes in Lucene, that Solr should > use. > Tasks here: > - Merge different versions into Lucene > - Make Solr classes use/extend the classes in Lucene (we need to keep the > Solr ones for backwards-compatibility) > - Deprecate the classes in Solr > - Change all references in Solr to use the classes in Lucene > One difficulty here is Solr's BitSetIterator vs. Lucene's OpenBitSetIterator. > Both have a next() method, however one returns an int (BitSetIterator), the > other one returns a boolean and offers a doc() method to get the doc id. So I > can't make BitSetIterator extend OpenBitSetIterator. There are not many > places in Solr's core that use BitSetIterator, so we could simply change e.g. > search/BitDocSet.java to use OpenBitSetIterator. This would however require > to change the call to next() into two calls to next() and doc(). I wonder if > this would be a noticeable performance hit? > We could of course also leave both iterators and only merge OpenBitSet and > BitUtil, but I'd prefer to only have one iterator, because they basically do > exactly the same. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-341) PHP Solr Client
[
https://issues.apache.org/jira/browse/SOLR-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650781#action_12650781
]
Pieter Berkel commented on SOLR-341:
Thanks for the quick response, just wanted to check that you uploaded the
updated class files? I couldn't find the new setBoost() / setField() /
setFieldBoost() methods in the Document class located in
SolrPhpClient.2008-11-24.zip
> PHP Solr Client
> ---
>
> Key: SOLR-341
> URL: https://issues.apache.org/jira/browse/SOLR-341
> Project: Solr
> Issue Type: New Feature
> Components: clients - php
>Affects Versions: 1.2
> Environment: PHP >= 5.2.0 (or older with JSON PECL extension or other
> json_decode function implementation). Solr >= 1.2
>Reporter: Donovan Jimenez
>Priority: Trivial
> Fix For: 1.4
>
> Attachments: SolrPhpClient.2008-09-02.zip,
> SolrPhpClient.2008-11-14.zip, SolrPhpClient.2008-11-24.zip, SolrPhpClient.zip
>
>
> Developed this client when the example PHP source didn't meet our needs. The
> company I work for agreed to release it under the terms of the Apache License.
> This version is slightly different from what I originally linked to on the
> dev mailing list. I've incorporated feedback from Yonik and "hossman" to
> simplify the client and only accept one response format (JSON currently).
> When Solr 1.3 is released the client can be updated to use the PHP or
> Serialized PHP response writer.
> example usage from my original mailing list post:
> require_once('Solr/Service.php');
> $start = microtime(true);
> $solr = new Solr_Service(); //Or explicitly new Solr_Service('localhost',
> 8180, '/solr');
> try
> {
> $response = $solr->search('solr', 0, 10,
> array(/* you can include other parameters here */));
> echo 'search returned with status = ',
> $response->responseHeader->status,
> ' and took ', microtime(true) - $start, ' seconds', "\n";
> //here's how you would access results
> //Notice that I've mapped the values by name into a tree of stdClass
> objects
> //and arrays (actually, most of this is done by json_decode )
> if ($response->response->numFound > 0)
> {
> $doc_number = $response->response->start;
> foreach ($response->response->docs as $doc)
> {
> $doc_number++;
> echo $doc_number, ': ', $doc->text, "\n";
> }
> }
> //for the purposes of seeing the available structure of the response
> //NOTE: Solr_Response::_parsedData is lazy loaded, so a print_r on
> the response before
> //any values are accessed may result in different behavior (in case
> //anyone has some troubles debugging)
> //print_r($response);
> }
> catch (Exception $e)
> {
> echo $e->getMessage(), "\n";
> }
> ?>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-341) PHP Solr Client
[
https://issues.apache.org/jira/browse/SOLR-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donovan Jimenez updated SOLR-341:
-
Attachment: (was: SolrPhpClient.2008-11-24.zip)
> PHP Solr Client
> ---
>
> Key: SOLR-341
> URL: https://issues.apache.org/jira/browse/SOLR-341
> Project: Solr
> Issue Type: New Feature
> Components: clients - php
>Affects Versions: 1.2
> Environment: PHP >= 5.2.0 (or older with JSON PECL extension or other
> json_decode function implementation). Solr >= 1.2
>Reporter: Donovan Jimenez
>Priority: Trivial
> Fix For: 1.4
>
> Attachments: SolrPhpClient.2008-09-02.zip,
> SolrPhpClient.2008-11-14.zip, SolrPhpClient.zip
>
>
> Developed this client when the example PHP source didn't meet our needs. The
> company I work for agreed to release it under the terms of the Apache License.
> This version is slightly different from what I originally linked to on the
> dev mailing list. I've incorporated feedback from Yonik and "hossman" to
> simplify the client and only accept one response format (JSON currently).
> When Solr 1.3 is released the client can be updated to use the PHP or
> Serialized PHP response writer.
> example usage from my original mailing list post:
> require_once('Solr/Service.php');
> $start = microtime(true);
> $solr = new Solr_Service(); //Or explicitly new Solr_Service('localhost',
> 8180, '/solr');
> try
> {
> $response = $solr->search('solr', 0, 10,
> array(/* you can include other parameters here */));
> echo 'search returned with status = ',
> $response->responseHeader->status,
> ' and took ', microtime(true) - $start, ' seconds', "\n";
> //here's how you would access results
> //Notice that I've mapped the values by name into a tree of stdClass
> objects
> //and arrays (actually, most of this is done by json_decode )
> if ($response->response->numFound > 0)
> {
> $doc_number = $response->response->start;
> foreach ($response->response->docs as $doc)
> {
> $doc_number++;
> echo $doc_number, ': ', $doc->text, "\n";
> }
> }
> //for the purposes of seeing the available structure of the response
> //NOTE: Solr_Response::_parsedData is lazy loaded, so a print_r on
> the response before
> //any values are accessed may result in different behavior (in case
> //anyone has some troubles debugging)
> //print_r($response);
> }
> catch (Exception $e)
> {
> echo $e->getMessage(), "\n";
> }
> ?>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-341) PHP Solr Client
[
https://issues.apache.org/jira/browse/SOLR-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donovan Jimenez updated SOLR-341:
-
Attachment: SolrPhpClient.2008-11-25.zip
You are correct, I didn't zip up the updated files. I did the work on a
branch, but my build script takes from trunk.
This new one should be what you want - i double checked :P, sorry for the
confusion.
> PHP Solr Client
> ---
>
> Key: SOLR-341
> URL: https://issues.apache.org/jira/browse/SOLR-341
> Project: Solr
> Issue Type: New Feature
> Components: clients - php
>Affects Versions: 1.2
> Environment: PHP >= 5.2.0 (or older with JSON PECL extension or other
> json_decode function implementation). Solr >= 1.2
>Reporter: Donovan Jimenez
>Priority: Trivial
> Fix For: 1.4
>
> Attachments: SolrPhpClient.2008-09-02.zip,
> SolrPhpClient.2008-11-14.zip, SolrPhpClient.2008-11-25.zip, SolrPhpClient.zip
>
>
> Developed this client when the example PHP source didn't meet our needs. The
> company I work for agreed to release it under the terms of the Apache License.
> This version is slightly different from what I originally linked to on the
> dev mailing list. I've incorporated feedback from Yonik and "hossman" to
> simplify the client and only accept one response format (JSON currently).
> When Solr 1.3 is released the client can be updated to use the PHP or
> Serialized PHP response writer.
> example usage from my original mailing list post:
> require_once('Solr/Service.php');
> $start = microtime(true);
> $solr = new Solr_Service(); //Or explicitly new Solr_Service('localhost',
> 8180, '/solr');
> try
> {
> $response = $solr->search('solr', 0, 10,
> array(/* you can include other parameters here */));
> echo 'search returned with status = ',
> $response->responseHeader->status,
> ' and took ', microtime(true) - $start, ' seconds', "\n";
> //here's how you would access results
> //Notice that I've mapped the values by name into a tree of stdClass
> objects
> //and arrays (actually, most of this is done by json_decode )
> if ($response->response->numFound > 0)
> {
> $doc_number = $response->response->start;
> foreach ($response->response->docs as $doc)
> {
> $doc_number++;
> echo $doc_number, ': ', $doc->text, "\n";
> }
> }
> //for the purposes of seeing the available structure of the response
> //NOTE: Solr_Response::_parsedData is lazy loaded, so a print_r on
> the response before
> //any values are accessed may result in different behavior (in case
> //anyone has some troubles debugging)
> //print_r($response);
> }
> catch (Exception $e)
> {
> echo $e->getMessage(), "\n";
> }
> ?>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-883) Cores created through Admin do not have the implicit properties set
Cores created through Admin do not have the implicit properties set --- Key: SOLR-883 URL: https://issues.apache.org/jira/browse/SOLR-883 Project: Solr Issue Type: Bug Reporter: Noble Paul Fix For: 1.4 When a core is present in the solr.xml , the core has all the implicit properties set. But when it is created through the REST API. It is not set -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
