Giving credit to sponsors?
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 first and easiest thing that comes to my mind is the creation of the Sponsors page on the Wiki to hold information about all sponsors, perhaps list who did what work, and such. Any better ideas? Thanks, Otis
[jira] Commented: (SOLR-30) Java client code for performing searches against a Solr instance
[ 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 SOLR-20. Close this? Java client code for performing searches against a Solr instance Key: SOLR-30 URL: https://issues.apache.org/jira/browse/SOLR-30 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Philip Jacob Priority: Minor Attachments: solrsearcher-client.zip Here are a few classes that connect to a Solr instance to perform searches. Results are returned in a Response object. The Response encapsulates a ListMapString,Field that gives you access to the key data in the results. This is the main part that I'm looking for comments on. There are 2 dependencies for this code: JDOM and Commons HttpClient. I'll remove the JDOM dependency in favor of regular DOM at some point, but I think that the HttpClient dependency is worthwhile here. There's a lot that can be exploited with HttpClient that isn't demonstrated in this class. The purpose here is mainly to get feedback on the API of SolrSearcher before I start optimizing anything. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] graduate Solr to Lucene subproject
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 [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 PMC to graduate Solr from the Incubator to become a Lucene subproject. [ ] 0 Don't care [ ] -1 Not at this time, stay in the Incubator for now.
Re: [VOTE] graduate Solr to Lucene subproject
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'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 PMC to graduate Solr from the Incubator to become a Lucene subproject. [ ] 0 Don't care [ ] -1 Not at this time, stay in the Incubator for now.
Re: SQL UpdatePlugin?
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 immediately anyway, if needed ;-) Putting TODO comments in your code in places where you feel others should have a look can help if you're unsure about how to best implement certain things. -Bertrand
Re: Giving credit to sponsors?
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.org/repos/asf/cocoon/branches/BRANCH_2_1_X/CREDITS.txt I'm thinking of the Community Credits part a the top, the rest is covered by our NOTICE.txt file. Putting this stuff besides the LICENCE.txt and NOTICE.txt files makes sense IMHO, as this is similar to licence and software credits info. The website could say look at the CREDITS.txt file with a link to the SVN version like above. -Bertrand
Re: [Solr Wiki] Update of CommonQueryParameters by ThorstenScherler
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 are additive. Do
not try to add more then one filter to each fq, since only the first one will
be taken. So instead of {{{
+ fq=date:[* TO 26-10-2006] section:0}}} you need to use {{{
+ fq=date:[* TO 26-10-2006]fq=section:0}}}
Actually, that's not quite right... you can add multiple clauses to a single fq.
Your example fq is in lucene query syntax and thus means
date:[* TO 26-10-2006] OR section:0
You could do fq=+date:[* TO 26-10-2006] +section:0
and that would be functionally equivalent to
fq=date:[* TO 26-10-2006]fq=section:0
The difference comes mostly in caching... fq's are cached
independently, so for best efficiency, one would want to use the
former if those clauses appeared together often, and the latter of
they were relatively independent.
-Yonik
Re: Update Plugins (was Re: Handling disparate data sources in Solr)
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 updateHandler already is in SolrCore
Re: [VOTE] graduate Solr to Lucene subproject
: 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 : : 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 [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 PMC to graduate Solr from the : Incubator to become a Lucene subproject. : [ ] 0 Don't care : [ ] -1 Not at this time, stay in the Incubator for now. : -Hoss
[jira] Created: (SOLR-101) 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.local 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386 Reporter: Ed Summers Major refactoring of lib/solr/request.rb: - split out different classes into Solr::Request module - all requests inherit from Solr::Request::Base - added Solr::Document and Solr::Field classes - adjusted unit tests appropriately - functional tests not working currently -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-101) 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.patch 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.local 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386 Reporter: Ed Summers Attachments: request_refactoring.patch Major refactoring of lib/solr/request.rb: - split out different classes into Solr::Request module - all requests inherit from Solr::Request::Base - added Solr::Document and Solr::Field classes - adjusted unit tests appropriately - functional tests not working currently -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Update Plugins (was Re: Handling disparate data sources in Solr)
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 the same class)
QueryResponseWriter = UpdateResponseWriter (possible the same class)
...is that with queries, the input tends to be fairly simple. very
generic code can be run by the query Servlet to get all of the input
params and build the SolrQueryRequest ... but with updates this isn't
quite as simple. there's the two issues i spoke of in my earlier mail
which should be independenly confiugable:
1) where does the stream of update data come from? is it in the raw
POST body? is it in a POSTed multi-part MIME part? is it a remote
resource refrenced by URL?
2) how should the raw binary stream of update data be parsed? is it
XML? (in the current update format) is it a CSV file? is it a PDF?
...#2 can be what the SolrUpdateHandler interface is all about -- when
hitting the update url you specify a ut (update type) that determines
that logic ... but it should be independed of #1
Right, you're getting at issues of why I haven't committed my CSV handler yet.
It currently handles reading a local file (this is more like an SQL
update handler... only a reference to the data is passed). But I also
wanted to be able to handle a POST of the data , or even a file
upload from a browser. Then I realized that this should be generic...
the same should also apply to XML updates, and potential future update
formats like JSON.
The most important issue is to nail down the external HTTP interface.
If the URL structure changes, it's also an opportunity to change
whatever we don't like about the current XML format. The old update
URL can still implement the original syntax.
It's also an opportunity to make the interface a little more REST-like
if we so choose.
Brainstorming:
- for errors, use HTTP error codes instead of putting it in the XML as now.
- perhaps get rid of the enclosing add... that could be a verb in
the URL, or for multiple documents, change it to docs.
- add information about the data in the URL:
POST /solr/add?format=jsonoverwrite=true
[
{field1:value1, field2:[false,true,false,true,true]}
]
POST /solr/add?format=csvseparator=,...
field1,field2
val1,val2
This is more flexible as it allows one to add more metadata about the
data w/o having to change the data format. For example, if one wanted
to be able to specify which index the add should go to, or other info
about the handling of the data, it's simple to add an additional param
in the URL.
- For browser friendliness, we could support a standard mechanism for
putting the body in the URL (not for general use since the URL can be
size limited, but good for testing).
POST /solr/add?format=jsonoverwrite=truebody=[{field1:value1}]
- more REST like?
PUT /solr/document/1003?title=howdyauthor=snafoocat=misccat=book
#not sure I like that format, and we would still want the multi-doc
format anyway
- more REST like?
DEL /solr/document/1003
OR
DEL /solr/document?id=1003
OR
POST /solr/document/delete?id=1003
#how to do delete-by-query, optimize, etc?
DEL/POST /solr/document/delete?q=id:[10 TO 20]
OR
POST /solr/command/delete?id=1002id=1003q=id:[1000 TO 1010]
OR
POST /solr/command/deletebyquery?q=id:[10 TO 20]
POST /solr/command/optimizewait=true
- administrative commands, setting certain limits
POST /solr/command/setmergeFactor=100maxBufferedDocs=1000
POST /solr/command/setlogLevel=3
You get the idea of some of the options available.
Ideas? Thoughts?
-Yonik
[jira] Updated: (SOLR-101) 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 -- Key: SOLR-101 URL: https://issues.apache.org/jira/browse/SOLR-101 Project: Solr Issue Type: Improvement Components: clients - ruby - flare Environment: Darwin frizz.local 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386 Reporter: Ed Summers Attachments: request_refactoring.patch, request_refactoring_with_ping.patch Major refactoring of lib/solr/request.rb: - split out different classes into Solr::Request module - all requests inherit from Solr::Request::Base - added Solr::Document and Solr::Field classes - adjusted unit tests appropriately - functional tests not working currently -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SQL UpdatePlugin?
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 bit misnamed in this context... they deal with the low-level lucene index munging and concurrency issues, more like an IndexWriter. 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? Should I post the code on a personal website? Yep, and adding a note that it's just a draft is important. Does this belong in the main package o.a.s.update? IMO, yes (or in o.a.s.update.db or sql). SQL databases are ubiquitous, and we don't want everyone having to do the same integration steps themselves to index their db content. 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 split on this one... It seems like it would be nice if we didn't have any vendor specific db stuff in the core or in the repository. On the other hand, if the vast majority of people will be using this with mysql, why make them go through the trouble. -Yonik
[jira] Resolved: (SOLR-91) warming searchers can stack up
[ 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 -- Key: SOLR-91 URL: https://issues.apache.org/jira/browse/SOLR-91 Project: Solr Issue Type: Improvement Affects Versions: 1.1.0 Reporter: Yonik Seeley Attachments: maxWarmingSearchers.patch If the commit frequency is high, and searcher warming configured, sometimes an overlap of warming searchers can occur. Solr currently detects this and logs a warning message. While normally relatively harmless, multiple warming searchers can sometimes cause thrashing, extending the time it takes to complete warming, and causing a chain reaction where more and more searchers try to warm concurrently. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Update Plugins (was Re: Handling disparate data sources in Solr)
- 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=valueparam=value...
or:
/solr/${verb}/${handler}/?param=valueparam=value...
Commands should work with or without the trailing '/'
/solr/query should continue to support qt=dismax, but I don't think we
should add params for 'at' (add type) 'ct' (commit type) etc...
Examples:
/solr/query/?q=... (use standard)
/solr/query/dismax/?q=...
/solr/add/
POST: docs.../docs
/solr/add/sql/?q=SELECT *
/solr/add/csv/?param=xxx...
POST (fileupload): file.csv
/solr/commit/?waitSearcher=true
/solr/delete/?id=AAAid=BBBq=id:[* TO CCC]
/solr/optimize/?waitSearcher=true
RequestHandlers would be registered with a verb (command?) in solrconfig.xml
requestHandler command=query name=dismax ...
requestHandler command=add name=xml class=..
requestHandler command=add name=sql class=..
requestHandler command=commit ..
RequestHandlers would register verb/name not just name. It would also
be nice to specify the default handler in solrconfig.xml (rather then
hardcoded to 'standard')
requestHandler command=query name=dismax isDefault=true
DEL /solr/document?id=1003
OR
POST /solr/document/delete?id=1003
I think the request method should be added to the base SolrRequest and
let the handler decide if it will do something different for GET vs.
POST vs. DEL
Conceptually /commit should be a POST, but it may be nice to use your
bowser (GET) to run commands like:
/solr/commit?waitSearcher=true
If the method is passed to the RequestHandler, this will let anyone
who is unhappy with the standard behavior change it easily. Someone
may want to require you send DEL to delete and POST to change anything
-- or the opposite if you care.
- administrative commands, setting certain limits
POST /solr/command/setmergeFactor=100maxBufferedDocs=1000
POST /solr/command/setlogLevel=3
In my proposal, this could be something like:
/solr/setconfig?logLevel=3
If someone wrote a handler that set the variables, then saved them in
solrconfig.xml, it could be:
/solr/setconfig/save/?mergeFactor=100
good good
ryan
[jira] Commented: (SOLR-60) Remove overwritePending, overwriteCommitted flags?
[ 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 :) Remove overwritePending, overwriteCommitted flags? -- Key: SOLR-60 URL: https://issues.apache.org/jira/browse/SOLR-60 Project: Solr Issue Type: Improvement Components: update Reporter: Yonik Seeley Priority: Minor The overwritePending, overwriteCommitted, allowDups flags seem needlessly complex and don't add much value. Do people need/use separate control over pending vs committed documents? Perhaps all most people need is overwrite=true/false? overwritePending, overwriteCommitted were originally added because it was a (mis)feature that another internal search tool had. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SQL UpdatePlugin?
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 split on this one... It seems like it would be nice if we didn't have any vendor specific db stuff in the core or in the repository. On the other hand, if the vast majority of people will be using this with mysql, why make them go through the trouble. Perhaps we could add an 'ext' directory to lib where we put libraries used by many plugins, but are not essential to solr. These would probably include: commons-fileupload-1.1.1.jar mysql-connector-java-5.0.4.jar postgresql.jar (i don't actually know what it is called) poi-2.5.1.jar commons-csv-20061121.jar If people are worried about a more lean distribution, there could be a 'core' and 'complete' version. At least this would solve my current problem: where to put the libraries for unit testing!
[jira] Resolved: (SOLR-9) In would be handy if StandardRequestHandler returned an error when a query requested sorting on a non-indexed field
[ 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 returned an error when a query requested sorting on a non-indexed field --- Key: SOLR-9 URL: https://issues.apache.org/jira/browse/SOLR-9 Project: Solr Issue Type: Improvement Components: search Reporter: Ken Krugler Priority: Minor Currently if you send Solr a query which includes a sorting specification, and the field you're trying to sort on is not indexed, then there's no error response, but the result returned isn't sorted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SOLR-99) Allow default sort order
[
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
Key: SOLR-99
URL: https://issues.apache.org/jira/browse/SOLR-99
Project: Solr
Issue Type: Improvement
Components: search
Affects Versions: 1.2
Reporter: Ryan McKinley
Priority: Minor
Fix For: 1.2
Attachments: DefaultSortOrder.patch, DefaultSortOrder.patch,
DefaultSortOrder.patch
The current search throws an ArrayIndexOutOfBoundsException if you specify
a sort field but do not include an order. This is anoying and difficult to
debug (when you are starting)
Here is a patch to avoid the exception and use the default sort order if you
only specify a field. I'm not sure the 'null' case was even possible in the
current code:
Index: QueryParsing.java
===
--- QueryParsing.java (revision 494681)
+++ QueryParsing.java (working copy)
@@ -186,13 +186,12 @@
}
// get the direction of the sort
- str=parts[pos];
- if (top.equals(str) || desc.equals(str)) {
-top=true;
- } else if (bottom.equals(str) || asc.equals(str)) {
-top=false;
- } else {
-return null; // must not be a sort command
+ // by default, top is true, only change it if it is bottom or asc
+ if( parts.length pos ) {
+ str=parts[pos];
+ if (bottom.equals(str) || asc.equals(str)) {
+ top=false;
+ }
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-60) Remove overwritePending, overwriteCommitted flags?
[ 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 to them, and add additional support for overwrite=true/false in the code. Remove overwritePending, overwriteCommitted flags? -- Key: SOLR-60 URL: https://issues.apache.org/jira/browse/SOLR-60 Project: Solr Issue Type: Improvement Components: update Reporter: Yonik Seeley Priority: Minor The overwritePending, overwriteCommitted, allowDups flags seem needlessly complex and don't add much value. Do people need/use separate control over pending vs committed documents? Perhaps all most people need is overwrite=true/false? overwritePending, overwriteCommitted were originally added because it was a (mis)feature that another internal search tool had. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Update Plugins (was Re: Handling disparate data sources in Solr)
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 for Query vs Update? I think the most flexible system would have the plugin manager take any HttpServletRequest, convert it to a 'SolrRequest' and pass it to a RequestHandler. SolrRequest would be the current SolrQueryRequest augmented with the HTTP method type and a way to get the raw post stream. Likewise I don't see anything in QueryResponseWriter that should tie it to 'Query.' Could it just be ResponseWriter? This way the plugin system would not need to care if its a query/update/ or some other command someone wants to add. 1) where does the stream of update data come from? is it in the raw POST body? is it in a POSTed multi-part MIME part? is it a remote resource refrenced by URL? I'm not sure the nitty gritty, but it should be as close to HttpServletRequest as possible. If possible, I think handlers should choose how to handle the stream. It it is a remote resource, I think its the handlers job to open the stream. 2) how should the raw binary stream of update data be parsed? is it XML? (in the current update format) is it a CSV file? is it a PDF? ...#2 can be what the SolrUpdateHandler interface is all about -- when hitting the update url you specify a ut (update type) that determines that logic ... but it should be independed of #1 maybe the full list of stream sources for #1 is finite and the code for all of them can live in the UpdateServlet ... but it still needs to be an option configured as a param, and it seems like it might as well be a plugin so it's easy for people to write new ones in the future. -Hoss While we are at it... is there any reason (for or against) exposing other parts of the HttpServletRequest to SolrRequestHandlers? While it is not the focus of solr, someone (including me!) may want to implement some more complex authentication scheme - Perhaps setting a field on each document saying who added it and from what IP. stuff to consider: cookies, headers, remoteUser, remoteHost... ryan
[jira] Created: (SOLR-102) 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 Assigned To: Mike Klaas Priority: Minor Attachments: RegexFragmenter.java A collection of rough enhancements to the default highlighter. Mostly to be used as ideas for future development. RegexFragmenter - Define a regular expression to indicate points of interest inthe target text (eg., beginning/end of sentences). Fragmenter will attempt to start/end fragments at these locations -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-102) Ideas for better highlighting
[ 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 - Key: SOLR-102 URL: https://issues.apache.org/jira/browse/SOLR-102 Project: Solr Issue Type: Improvement Components: search Reporter: Mike Klaas Assigned To: Mike Klaas Priority: Minor Attachments: RegexFragmenter.java A collection of rough enhancements to the default highlighter. Mostly to be used as ideas for future development. RegexFragmenter - Define a regular expression to indicate points of interest inthe target text (eg., beginning/end of sentences). Fragmenter will attempt to start/end fragments at these locations -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-101) 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 -- Key: SOLR-101 URL: https://issues.apache.org/jira/browse/SOLR-101 Project: Solr Issue Type: Improvement Components: clients - ruby - flare Environment: Darwin frizz.local 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386 Reporter: Ed Summers Attachments: request_refactoring.patch, request_refactoring_with_ping.patch, request_refactoring_with_ping.patch Major refactoring of lib/solr/request.rb: - split out different classes into Solr::Request module - all requests inherit from Solr::Request::Base - added Solr::Document and Solr::Field classes - adjusted unit tests appropriately - functional tests not working currently -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-101) refactored request classes
[ 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 -- Key: SOLR-101 URL: https://issues.apache.org/jira/browse/SOLR-101 Project: Solr Issue Type: Improvement Components: clients - ruby - flare Environment: Darwin frizz.local 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386 Reporter: Ed Summers Attachments: request_refactoring_with_ping.patch, request_refactoring_with_ping.patch Major refactoring of lib/solr/request.rb: - split out different classes into Solr::Request module - all requests inherit from Solr::Request::Base - added Solr::Document and Solr::Field classes - adjusted unit tests appropriately - functional tests not working currently -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SOLR-101) refactored request classes
[ 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 below 100% :) 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.local 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386 Reporter: Ed Summers Assigned To: Erik Hatcher Attachments: request_refactoring_with_ping.patch, request_refactoring_with_ping.patch Major refactoring of lib/solr/request.rb: - split out different classes into Solr::Request module - all requests inherit from Solr::Request::Base - added Solr::Document and Solr::Field classes - adjusted unit tests appropriately - functional tests not working currently -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
memcached SolrCache implementation?
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 the SolrCache interface, it seems like this is doable. I don't believe it's possible to implement autowarming, as there doesn't seem to be a way to get a list of cached keys from the memcached library. Can someone comment on whether this seems like a good idea? I would like to dig in the Solr internals, and this seems like a good starting point. If so, I'm not certain how to pass up additional arguments to a custom SolrCache implementation - I'd like to replace queryResultCache with my implementation, but will need to provide additional configuration - memcache server string, etc. Is it permissible to add custom attributes to the queryResultCache configuration node? Thanks for the feedback -Shawn
