Hi devs,
I'd like to see about making a SolrCache implementation that uses the
memcached library @ http://www.whalin.com/memcached/. I believe that
this would be useful for replicated sites, allowing all the search nodes
to use a shared global cache.
From my reading of the LRUCache code and
[
https://issues.apache.org/jira/browse/SOLR-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher resolved SOLR-101.
---
Resolution: Fixed
Assignee: Erik Hatcher
Committed. Thanks Ed, even though code coverage dipped
[
https://issues.apache.org/jira/browse/SOLR-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-101:
--
Attachment: (was: request_refactoring.patch)
> refactored request classes
> -
[
https://issues.apache.org/jira/browse/SOLR-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Summers updated SOLR-101:
Attachment: request_refactoring_with_ping.patch
> refactored request classes
> --
>
>
[
https://issues.apache.org/jira/browse/SOLR-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated SOLR-102:
Attachment: RegexFragmenter.java
> Ideas for better highlighting
> -
>
>
Ideas for better highlighting
-
Key: SOLR-102
URL: https://issues.apache.org/jira/browse/SOLR-102
Project: Solr
Issue Type: Improvement
Components: search
Reporter: Mike Klaas
Assign
SolrRequestHandler => SolrUpdateHandler
SolrQueryRequest => SolrUpdateRequest
SolrQueryResponse => SolrUpdateResponse (possibly the same class)
QueryResponseWriter => UpdateResponseWriter (possible the same class)
Is there any reason the plugin system needs a different RequestObject
fo
[
https://issues.apache.org/jira/browse/SOLR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464379
]
Yonik Seeley commented on SOLR-60:
--
Well, we can deprecate the current flags and remove all documentation
references t
[
https://issues.apache.org/jira/browse/SOLR-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-99.
--
Resolution: Fixed
Committed. Thanks Ryan!
> Allow default sort order
>
>
>
[
https://issues.apache.org/jira/browse/SOLR-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-9.
-
Resolution: Fixed
SOLR-99 resolution fixed this issue.
> In would be handy if StandardRequestHandler returne
> or a 'contrib'
> package/project/source folder? If it is in the main tree: the unit
> tests require mysql-connector.jar and assume you have a database at:
> jdbc:mysql://localhost/solrtestsql with user=solr and password=solr.
> Any suggestions on how this should be handled or structured.
I'm
[
https://issues.apache.org/jira/browse/SOLR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464376
]
Ryan McKinley commented on SOLR-60:
---
I like overwrite=true/false better, but i don't have any legacy solr code :)
> R
- for errors, use HTTP error codes instead of putting it in the XML as now.
yes!
- more REST like?
I would like the URL form to look like this:
/solr/${verb}/?param=value¶m=value...
or:
/solr/${verb}/${handler}/?param=value¶m=value...
Commands should work with or without the trailing
[
https://issues.apache.org/jira/browse/SOLR-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-91.
--
Resolution: Fixed
committed.
> warming searchers can stack up
> --
>
>
On 1/12/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
For now, it extends SolrRequestHandler (not UpdateHandler) because the
request plugin framework seems more stable.
There is no framework for pluggable update handlers yet...
Solr's current UpdateHandler classes (DirectUpdateHandler2) are a bi
[
https://issues.apache.org/jira/browse/SOLR-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Summers updated SOLR-101:
Attachment: request_refactoring_with_ping.patch
> refactored request classes
> --
>
>
On 1/10/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
The one hitch i think to the the notion that updates and queries map
cleanlly with something like this...
SolrRequestHandler => SolrUpdateHandler
SolrQueryRequest => SolrUpdateRequest
SolrQueryResponse => SolrUpdateResponse (possibly t
[
https://issues.apache.org/jira/browse/SOLR-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Summers updated SOLR-101:
Attachment: request_refactoring.patch
> refactored request classes
> --
>
>
refactored request classes
--
Key: SOLR-101
URL: https://issues.apache.org/jira/browse/SOLR-101
Project: Solr
Issue Type: Improvement
Components: clients - ruby - flare
Environment: Darwin frizz.loc
: Date: Fri, 12 Jan 2007 11:26:51 -0500
: The Lucene PMC has voted to accept Solr, and I've called a vote in the
: Incubator.
: If you have a binding vote there, please vote!
wow ... we might acctually graduate on the 1 year aniversary of entering
incubation (2006-01-17) ... cool.
:
: -Yonik
:
Is there any reason anyone would want/need to run multple Indexers?
This would be the equivolent of running DirectUpdateHandler and
DirectUpdateHandler2 at the same time. If not, the Indexer could be
stored in SolrCore and each plugin could talk to it directly.
I just realized that the update
What do you folks think?
I like it! I'm currently writing an update plugin that is extended
from SolrRequestHandler because it has the default parameter stuff and
is easily configurable.
Do all UpdatePlugins need to implement:etc?
In practice, it seems like most plugins will override (
On 1/12/07, Apache Wiki <[EMAIL PROTECTED]> wrote:
The following page has been changed by ThorstenScherler:
http://wiki.apache.org/solr/CommonQueryParameters
- This param can be specified multiple times, and the filters are additive.
+ This param can be specified multiple times, and the filters
On 1/12/07, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
Are there existing practices for giving credit to companies that "sponsor"
development of Solr (or Nutch or Lucene or ...) by paying consultants/developers to work
on Solr (or Nutch or ...) and contribute their work back to ASF?
If there
Any reason we shouldn't switch to native locks by default?
In the future, read-only readers won't lock at all, but there will
still be a write lock for writers.
-Yonik
On 1/12/07, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
...Are there existing practices for giving credit to companies that "sponsor"
development of Solr..
I don't think we have something like that yet. Cocoon 2.1.x has a
CREDITS.txt file for listing such contributions:
http://svn.apache.or
On 1/12/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
...What is the best way to post unfinished code and ask for review?
Should i make a JIRA issue and post a patch with a "not ready for
prime time" note? ...
Yes, this would work. Our personal NotReadyForPrimeTime detectors
would flag it immed
Fingers crossed!!!
simon
On 1/12/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
The Lucene PMC has voted to accept Solr, and I've called a vote in the
Incubator.
If you have a binding vote there, please vote!
-Yonik
On 1/8/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> This vote has passed, and I
The Lucene PMC has voted to accept Solr, and I've called a vote in the
Incubator.
If you have a binding vote there, please vote!
-Yonik
On 1/8/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
This vote has passed, and I've just called for a vote within the Lucene PMC.
-Yonik
On 1/4/07, Yonik Seeley
[
https://issues.apache.org/jira/browse/SOLR-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464182
]
Otis Gospodnetic commented on SOLR-30:
--
I think this issue is now out of date - it looks like moved everything to
Hi,
Are there existing practices for giving credit to companies that "sponsor"
development of Solr (or Nutch or Lucene or ...) by paying
consultants/developers to work on Solr (or Nutch or ...) and contribute their
work back to ASF?
If there are no existing practices, any suggestions? The fir
31 matches
Mail list logo
