[
https://issues.apache.org/jira/browse/SOLR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher resolved SOLR-97.
--
Resolution: Fixed
Assignee: Erik Hatcher
Applied. Thanks again, Ed!
Note: be sure to svn add file
: Thanks for the clarification. I'm still not sure why you decided to let
: Ant control the version of JUnit that Solr gets to use (by expecting the
: JUnit JAR to be in ANT_HOME/lib). My Eclipse installation places the Ant
It wasn't an explict decision on my part, so much as the convention:
a) r
[
https://issues.apache.org/jira/browse/SOLR-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-51:
-
Component/s: clients - php
> SolrQuery - PHP query client for Solr
> -
>
>
[
https://issues.apache.org/jira/browse/SOLR-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-50:
-
Component/s: (was: update)
clients - php
> SolrUpdate - PHP update client for Solr
> --
Chris Hostetter wrote:
: The design issue for this is to be clear about the schema and how
: documents are mapped into the schema. If all document types are
: mapped into the same schema, then one type of query will work
: for all. If the documents have different schemas (in the search
: index),
This vote has passed, and I've just called for a vote within the Lucene PMC.
-Yonik
On 1/4/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
It's time that Solr graduate from the incubator and become an official
Lucene subproject.
So, please cast your votes:
[ ] +1 ask Lucene PMC and the Incubator P
Chris H.,
>Chris: As mentioned in the Solr FAQ, (and the Ant FAQ) for proper
>JUnit/Ant integration, the JUnit jars need to be in the ANT_HOME/lib
>directory. (the build file was modified just after 1.1.0 was released to
>make this error more informative). If JUnit is installed in this way, no
>
[
https://issues.apache.org/jira/browse/SOLR-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463129
]
Yonik Seeley commented on SOLR-98:
--
Unless someone has a better starting point for a python client, I'll commit
this o
[
https://issues.apache.org/jira/browse/SOLR-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-98:
-
Attachment: solr.py
> simple python client
>
>
> Key: SOLR-98
>
simple python client
Key: SOLR-98
URL: https://issues.apache.org/jira/browse/SOLR-98
Project: Solr
Issue Type: New Feature
Components: clients - python
Reporter: Yonik Seeley
I've had this python
[
https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463125
]
Ryan McKinley commented on SOLR-69:
---
Thanks. it works great. The only problem i ran into is a null pointer if you
d
Ok, let me show an example. Assume, I want to perform the following
search: cat AND dog. I can perform it 3 different ways:
a) simply search for: cat AND dog (cat +dog)
b) search for: cat dog (assuming schema.xml has
c) search for: cat dog (passing q.op=AND query parameter to the
requesthandler
: The design issue for this is to be clear about the schema and how
: documents are mapped into the schema. If all document types are
: mapped into the same schema, then one type of query will work
: for all. If the documents have different schemas (in the search
: index), then the query needs an
: I would like to know if there is a way to support prefix, phrase, etc queries
: in solr. I know that the queries, such as solr* and "solr" would do the
trick,
: but I am looking for a solution similar to the SolrQueryParser defaultOperator
: setting (with q.op={OR|AND} or in the schema config
Hi,
I would like to know if there is a way to support prefix, phrase, etc queries
in solr. I know that the queries, such as solr* and "solr" would do the trick,
but I am looking for a solution similar to the SolrQueryParser defaultOperator
setting (with q.op={OR|AND} or in the schema config fil
On 1/7/07 7:24 AM, "Erik Hatcher" <[EMAIL PROTECTED]> wrote:
> The idea of having Solr handle various document types is a good one,
> for sure. I'm not sure what specifics would need to be implemented,
> but I at least wanted to reply and say its a good idea!
The design issue for this is to be c
[
https://issues.apache.org/jira/browse/SOLR-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated SOLR-50:
Summary: SolrUpdate - PHP update client for Solr (was: SolrUpdate)
> SolrUpdate - PHP update
[
https://issues.apache.org/jira/browse/SOLR-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated SOLR-51:
Summary: SolrQuery - PHP query client for Solr (was: SolrQuery)
> SolrQuery - PHP query clien
[
https://issues.apache.org/jira/browse/SOLR-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated SOLR-30:
Component/s: (was: search)
clients - java
> Java client code for performi
[
https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated SOLR-20:
Component/s: (was: update)
clients - java
> A simple Java client with Jav
[
https://issues.apache.org/jira/browse/SOLR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Summers updated SOLR-97:
---
Attachment: split_out_tests.patch
> Rakefile now supports functional and unit tests
> --
Rakefile now supports functional and unit tests
---
Key: SOLR-97
URL: https://issues.apache.org/jira/browse/SOLR-97
Project: Solr
Issue Type: Improvement
Components: clients - ruby - flar
On Jan 8, 2007, at 5:45 AM, Alan Burlison wrote:
Erik Hatcher wrote:
The Lucene in Action codebase has a DocumentHandler interface that
could be used for this, which has implementations for Word, PDF,
HTML, RTF, and some others. It's simplistic, so it might not be
of value specifically.
Erik Hatcher wrote:
There really is no question of "if" Solr can be made to handle it. :)
The "if" was a tuits "if", not a technical "if" ;-)
POSTing an encoded binary document in XML will work, and it certainly
will work to have Solr unencode it and parse it.
Yes, but the bits aren't the
On Jan 8, 2007, at 4:58 AM, Alan Burlison wrote:
I'm in the process of evaluating what we are going to do with the
search functionality for http://opensolaris.org, and at the moment
Solr is my first choice to replace what we already have - *if* it
can be made to handle disparate data source
Chris Hostetter wrote:
what do you guys think?
I'm going to spend some time today looking at the Solr source and
matching your suggestions to it, hopefully I'll be more able to give a
slightly more considered opinion after that ;-)
I'm in the process of evaluating what we are going to do w
26 matches
Mail list logo
