Chris Hostetter wrote:
: + If termVectors are not stored, !MoreLikeThis will generate terms from
: stored fields. If multiple fields are used for similarity, solr will
: use the default Analyzer -- NOTE: this may or ''may not'' match the
: Analyzer used to index the field. If only one field is
Chris Hostetter wrote:
: > (although an interesting question is what happens if i want to find
: > similar docs based on a field htat is stored by not indexed so it *really*
: > has no analyzer)
: I think the MLT implementation would need some modification to support
: that -- what you are sugge
small typo:
changes in behavior. For new-stype update handlers, errors are now
new-style
otherwise looks good
Excellent!
What are your final thoughts on the NIO issues in SOLR-128? Should we
change:
to:
or was it just a python client error?
Yonik Seeley wrote:
It looks to me like we're ready to cut a release.
I've tried out Solr on the latest versions of Tomcat/Jetty/Resin...
everything looks
Yonik Seeley wrote:
On 5/29/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
What are your final thoughts on the NIO issues in SOLR-128? Should we
change:
to:
Since it looks like it makes a big difference for Windows, I'd be in
favor of switching it (it was normally slightly fas
Chris Hostetter wrote:
: Now, the only status codes set in SolrExceptions are valid HTTP status codes:
: 500
: 400
: 503
: 404
should we deprecate the current SolrException constructor and add one that
uses an enumeration of legal HTTP status codes ... that way we can
eventually eliminate th
Chris Hostetter wrote:
: everything looks good license-wise to me.
I forgot LICENSE.txt has info on all the licenses involved (i thought
that was just suppose to be ASL and the dependency licenses were all
listed in NOTICES.txt)
LICENSE.txt still refers to Jetty 5.1,
updated in rev 542755
T
- - example/etc/LICENSE.javax.servlet.txt
- - example/etc/LICENSE.javax.xml.html
- - example/etc/LICENSE.jsse.txt
We actually don't need to mention anything for Jetty in LICENSE.txt if
it's all under the ASL2.0 But what about the CDDL license?
should we remove it from LICENSE.txt?
I thin
Just downloaded apache-solr-1.2.0.zip on vista. "ant example" works
fine (except for a bunch of "Warning: .. .java modified in the future.")
+1
Yonik Seeley wrote:
I propose to release the artifacts at
http://people.apache.org/~yonik/staging_area/solr/1.2/
as Apache Solr 1.2
They were creat
I found a rather severe error... my fault, part of SOLR-249
I noticed that:
http://localhost:8983/solr/update?stream.url=http://www.ask.com
does not give me an error (it should!)
In replacing the new SolrException( ), 2 files do not have the preceding
"throw" -- it makes exceptions, but does n
Yonik Seeley wrote:
Following a bug found and fixed by Ryan,
^ and *caused*!
I'm glad I happened to be working with something that touched the
problem today. SOLR-20 has some tests that fire up jetty, so next time
this will be less likely.
Here's my +1
(hopefully my
+1
Yonik Seeley wrote:
Sorry folks... one more time. This release candidate fixes SOLR-250
(scripts need to tell curl the content-type), as well as the minor
README typo.
Please vote to release the artifacts at
http://people.apache.org/~yonik/staging_area/solr/1.2rc3/
as Apache Solr 1.2
+1
How do you all feel about commiting SOLR-69?
It does not affect anyone who does not ask to use it...
Should we wait 'til 1.2 is successfully out before banging at trunk?
ryan
+1
Vista JDK 1.6
Yonik Seeley wrote:
OK, this one is it!
Please vote to release the artifacts at
http://people.apache.org/~yonik/staging_area/solr/1.2rc4/
as Apache Solr 1.2
+1
-Yonik
Chris Hostetter wrote:
: Any thoughts on adding the svn version info to the manifest
: Implementation-Version?
No objections from me. I didn't do it back in the day out of dislike for
the and task and fear that i would get it wrong and make Solr
completely unbuildable from source relases (eith
Chris Hostetter wrote:
: How do you all feel about commiting SOLR-69?
:
: It does not affect anyone who does not ask to use it...
i haven't really had a chance to follow along ... the biggest questions to
adding new functinality are "is the API clean? are we willing to support
the API going forw
I know this was mentioned recently... but it seems important to fix pre
1.2 official release.
The *"Faceted Searching With Apache Solr"* is a big bold link on the
front page that links to 404.
If we are uncomfortable updating the link to an existing file (so as not
to "edit history") we shou
I assume this is not something we worry about? It is just that husdon
svn checkout failed?
[EMAIL PROTECTED] wrote:
See http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/103/
--
started
Checking out http://svn.apache.org/repos/asf/lucene/solr
Has anyone had a chance to look at:
SOLR-135 and/or SOLR-193
I hope to get SOLR-20 integrated into trunk soon, so there is plenty of
time for it to mature before the next release. It is now reasonably
solid (thanks to help from Will Johnson)
thanks
ryan
ps. I think the "next solr" is bet
Looking toward the future, and distributed search, this might be a
natural place to add hooks to implement that distributed logic. This
would allow other people to efficiently support their custom
functionality in a distributed environment.
Thoughts?
I like it. As is the prospect of adding
I don't know about apache accounts - lucene has a 'contrib' area, and
guess we need something similar.
If its helpful, i can give you an account on: http://solrstuff.org/svn/
while we figure out something better. SOLR-20 is sitting there now
while I try to get it into trunk... since you
the second hitch is that "docs" only makes sense in ssuedo code ... in
reality there are DocSets and DocLists, and the efficiencies of geting
only one instead of both can be significant, but if the first phase of
processing doesn't know what expectations the later phases have (facet or
not? retu
:
: One interesting/difficult part would be the standardization of the
: communication between components.
Communication can be coordinated with things like
SolrQueryRequest.getContext() ... it will have to be fairly loose
communication governed by convetion, but i don't see anyway to avoid tha
On 6/11/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 6/11/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
> while (not all components done) {
> for (component : List) {
> boolean done = component.process(req,rsp);
> }
> }
> - - - - -
> Yonik, what comp
I hate to be a pest... but if anyone gets a change to look at either
of these, that would be great.
The changes are significant enough that I'd like something more then
silence before moving forward...
On 6/7/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
Has anyone had a chance
-
+ ${solr.data.dir:./solr/data}
+
I just ran into something weird with this...
If you set the solr home with JNDI or solr.solr.home, the dataDir still
defaults to "./solr/data" -- not the data directory relative to solr
home. This requires you to *also* set: "solr.data.dir" if you wa
Erik Hatcher wrote:
On Jun 12, 2007, at 1:34 AM, Ryan McKinley wrote:
-
+ ${solr.data.dir:./solr/data}
+
I just ran into something weird with this...
If you set the solr home with JNDI or solr.solr.home, the dataDir
still defaults to "./solr/data" -- not the data directory r
I'm ambivalent though - I'm happy to reverse the change to the example
solrconfig.xml too, though I like that one can fire up the example
configuration with a different data directory easily.
I am happy either way - relative to solr home or just commented out.
In this case, relative to sol
For anyone not following SOLR-135... there is discussion of some
changes to the jar fiels and package layout. For SOLR-20, some classes
need to be extracted from the main jar. We have two options:
1. Keep the package names as is and create a two jar files each with
classes in o.a.s.util
2
Ryan McKinley (JIRA) wrote:
[
https://issues.apache.org/jira/browse/SOLR-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley reassigned SOLR-135:
--
Assignee: Ryan McKinley
I plan to do this later this evening
Chris Hostetter wrote:
:
: 1. Using eclipse, refactor common classes and *move* them to the new
: 3. Add a @deprecated new class in the place of any moved class. The new
: class will have the same name and extend the old class. They will not
: have version history. These files will be deleted
Ryan McKinley (JIRA) wrote:
[
https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley reassigned SOLR-20:
-
I'm integrating SOLR-20 with trunk now...
The basic stuff is no pr
Chris Hostetter wrote:
: + 6. SOLR-20: Added a java client interface with two implementations. One
: +implementation uses commons httpclient to connect to solr via HTTP. The
: +other connects to solr directly. Check client/java/solrj. This addition
: +also includes tests that star
[junit] Test org.apache.solr.client.solrj.embedded.TestJettySolrRunner
FAILED
Is there any way to see what error it failed with? ant test-reports
hudson seems to have built fine:
http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/112/
This is the test that starts jetty (on po
dency on import
org.apache.solr.common.util.NamedList. I can't find this class. There's a
import org.apache.util.NamedList, but not a package called common.
Thanks,
jds
On 6/15/07, Ryan McKinley (JIRA) <[EMAIL PROTECTED]> wrote:
[
https://issues.apac
Just to be clean, you can (and should) keep using 1.2 for the solr
server; but solrj is only in the trunk (1.3) branch.
John Stewart wrote:
Aha, 1.3. Thanks, I'm using 1.2.
jds
On 6/15/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
after running "ant dist"
you wil
Chris Hostetter wrote:
: It might be best to just pursue the clover integration separately from
since the biggest benefit of clover is likely to be modifying the nightly
build to run it, and since we (may) have a problem with the nightly.sh
script and the new unit tests ryan wrote that run jetty
Yonik Seeley wrote:
On 6/16/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
Ryan: independent of the javadoc comment on loadStoredFields about it
possibly being refactored somwhere else, the build method doesn't really
match the semantics of the DocumentBuilder class.
i think i commented in SOLR
perhaps instead of a build method that returns a document, it just just be
a void processInputDocument method with usage like...
DocumentBuilder b = ;
for (SolrInputDocument i : ...) {
b.startDoc()
b.processInputDocument(i);
b.endDoc()
doSOmethingWith(b.getDoc());
Original Message
Subject: [Jetty-support] Release 6.1.4
Date: Sat, 16 Jun 2007 10:52:48 +1000
From: Greg Wilkins <[EMAIL PROTECTED]>
Reply-To: Jetty usage, help & informal support
<[EMAIL PROTECTED]>
To: Discussion for Jetty development.
<[EMAIL PROTECTED]>,
[EMAIL PROTECTE
Perhaps:
class DocumentUtils {
static Document toDocument( SolrInputDocument, Schema );
static SolrDocument loadFields( SolrDocument, Document, Schema,
boolean skipCopyFields)
}
thoughts?
Would request handlers (that are update handlers) call these directly
before passing a Lucene Docume
For the record nagios and/or cacti could both keep track of 'in the last
x' type of statistics based on totals but having solr compute that
automatically would be nice.
That's a good point about totals... totalResponseTime is actually more
powerful than averageResponseTime in that a monitoring
Will Johnson wrote:
Has anyone tried to get solr statistics with cacti/nagios? If it isn't
too difficult, I would like to set this up.
Can cacti read & parse a file?
Generally speaking nagios/cacti are as powerful as you are with bash.
We haven't done it yet but it's a requirement at my
Chris Hostetter wrote:
: SOLR-133: Adding StaxUpdateRequestHandler.java and mapping it to:
: http://localhost:8983/solr/admin/update/stax
: in the example solrconfig.xml
:
: We should test and evaluate this in comparison to the
: XmlUpdateRequestHandler before replacing it.
an easy way to sanit
I don't know if this is your issue, but in 1.2, we unified the response
format for /update and /select
Check the last paragraph in CHANGES.txt on "Upgrading from Solr 1.1"
To get the old behavior, make sure there is nothing in solrconfig.xml
mapped to "/update"
Fuad Efendi wrote:
I am not
should we update to latest stable builds?
* lucene-2.2
* jetty-6.1.4
You need to add something like:
"-Dsolr.test.sys.prop1=xxx -Dsolr.test.sys.prop2=xxx" to the VM
arguments in the Run panel.
It is kind of annoying they are required for all tests... ideally we
would move the schema property testing to an independent test, but that
has not happend yet.
Eri
I just did some performance testing to compare the stax vs xpp
implementaion. As far as I can tell there is no real difference between
them.
Using solrj, this adds 1 documents for each handler - running each
as an independent call.
STAX: 8631 8221 8525 8383 8487 = 42247
XPP: 8309 8438
I'm kinda out of the looop on the whole Stax/Xpp/Xml update parsing stuff
... am i remembering correctly the end game goal is to reduce/eliminate
dependencies on XPP? (because ? stax is Java "standard"
included out-of-the-box with java6? (i'm guessing))
For me the biggest reason is
so we should test that use case (ie: containing 1 small
documents;
For processing a single request with 1 documents, the existing XPP
update handler is faster then the new StaxUpdateHandler.
XPP: 6888 6714
STAX: 8665 8313
I looked into it, and the difference seems to be entirely
Yonik Seeley wrote:
On 6/29/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
How do you all feel about moving:
XmlUpdateRequestHandler -> XppUpdateRequestHandler
StaxUpdateRequestHandler -> XmlUpdateRequestHandler
then deprecating XppUpdateRequestHandler?
+1
I think we coul
Thoughts?
+1
It does feel a bit akward.
URL: http://svn.apache.org/viewvc?view=rev&rev=552683
Log:
SOLR-102 - regex fragmenter using SOLR-225 plugin framework
Mike - I did not add this to CHANGES.txt.
Do you want to?
[junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 7.177 sec
[junit] Test org.apache.solr.client.solrj.embedded.TestJettySolrRunner
FAILED
BUILD FAILED
Thoughts on what to do about this?
For starters, it would be great to have the ant test-reports output be
accessible to
It turns out this was a real failure. Each test tried to open a new
server without closing the last one. I fixed it in 552760.
I guess thats the problem with tests we expect to fail!
On 7/3/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
> [junit] Tests run: 2, Failures: 0,
If I get a chance I'll take a look to see what the problem is, but I
haven't touched this section of the code in quite a while.
I'm looking at it now... I'll at least add a test that fails for the
Stax version and passes Xpp.
ryan
Yonik Seeley wrote:
On 7/5/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
>
> If I get a chance I'll take a look to see what the problem is, but I
> haven't touched this section of the code in quite a while.
>
I'm looking at it now... I'll at least add a te
FYI, I'm working up a prototype right now to handle multiple request processors.
excellent.
check: https://issues.apache.org/jira/browse/SOLR-139
to see how I was thinking about supporting multiple processors.
Essentially a single parent processor that may loop through
'transformers' or wh
Looking back at SOLR-183 I see JJ had a comment about this...
One open question is getFieldParam: Should the semantics of
required.getFieldParam("facet.limit", "abc") be to fail if the
parameter is not supplied for the field (e.g. f.abc.facet.limit), or
not supplied for either the field or as a
Finer control would be interesting, but it would require substantial
work. As implemented, the real work happens in lucene contrib queries
MoreLikeThis implementation:
http://svn.apache.org/repos/asf/lucene/java/trunk/contrib/queries/src/java/org/apache/lucene/search/similar/
If you need to m
By taking the Query object returned by "mltquery = mlt.like(id);" (line
257)
and "mltquery = mlt.like(reader);" (line 274) and adding additional
BooleanClauses to it before the respective calls to searcher.getDocList()
(lines 269 & 278), I was hoping to modify the query used to generate the
lis
IMO, changes in implementation detail don't belong in CHANGES.txt,
unless it's to give credit to a contributor for that change (which
committers don't need).
With SOLR-292, it seems confusing to list a bug fix for something added
since the last release. But since it is from a new/useful cont
I just took a look at the files contained in:
http://people.apache.org/builds/lucene/solr/nightly/
the dist directory does not include the .jar files needed for solrj.
Can we modify the script to include 'solrj-lib'?
ryan
It looks like unlockOnStartup isn't working anymore. Perhaps this is a
side effect of SOLR-240?
I have a lock file:
lucene-884cd55a1a657c081e97fa89bfe5e084-write.lock
in solr/data/index/
I have unlockOnStartup set to true. I'm sure it is set because I'm
stepping through the debugger with ec
In the trunk code, the DocumentBuilder is not handling null values well.
SolrInputDocument doc = new SolrInputDocument();
doc.addField( "id", "hello", 1.0f );
doc.addField( "name", null, 1.0f );
Document out = DocumentBuilder.toDocument( doc, core.getSchema() );
throws an exception:
Say we were to come up with a FacetResult class... it would be
undesirable to have to add support in the response writers for
specific classes that will keep growing over time. So I guess a
FacetResult class would have to tell the writers how to access that
info, or export some sort of generic i
ponents: update
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Attachments: getStoredFields.patch, getStoredFields.patch,
getStoredFields.patch, getStoredFields.patch, getStoredFields.patch,
SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.p
>
objections?
It all sounds good to me!
ryan
Sorry for the deluge of SOLR-215 commits. I broke the standard
JIRA->svn policy after committing core changes and then working on SOLR-350.
After commiting SOLR-215, I found a bunch of stuff that would be better
if you all did not need to wade through. I removed it in subsequent
(non-JIRA) c
If anyone is concerned about this, i can rollback to pre rev573893 and
make a single patch that will be easier to try to follow. Otherwise, you
can see a unified diff for the current changes using:
Starting up the example now fails for me... is it working for others?
-Yonik
Try now. rev 574
Yonik Seeley wrote:
Closer... but the admin pages don't work yet.
try 574027
If you run into anymore problems I will definitely rollback to pre573893
and make a single clean patch.
ryan
did you apply the whole patch?
It also added a null check at line 59 of ClientUtils.java.
//--
Index:
client/java/solrj/src/org/apache/solr/client/solrj/util/ClientUtils.java
==
Mike Klaas wrote:
Core request handlers do not use this, favouring the new,
almost-identical code in the highlighting package. Deprecate or
delete? It is rather simple to upgrade code using this to the new regime.
Either way is fine by me.
Since it is advanced not really public API stuff,
Peuss, Thomas wrote:
Hello!
You might have seen my patch to SOLR-127.
I have a question there: why is Solr using a filter instead of a servlet
to answer search requests? I have seen that it used a servlet before.
Why was that changed to a filter? The speed gains are minimal from my
point of vie
Consider the case where legacy code calls SolrCore.getSolrCore() while
another thread is in the middle of executing the SolrCore constructor
(either directly, or because it called to getSolrCore()) ... won't it
have access to a "partially constructed" core before all of the
initialization is
i'm always a fan of quick fixes ... even if they are only temporary ...
but like i said, i'm confused as to why you wanted to avoid #1 or why #2
would breakthings.
sorry, my object to #1 was a synchronized map lookup. a simple
synchronized call should not hurt.
#2 breaks the Jetty test --
Yonik Seeley wrote:
ant test from the command line is currently failing.
compileTests:
[mkdir] Created dir: F:\code\solr\build\tests
[javac] Compiling 66 source files to F:\code\solr\build\tests
[javac] F:\code\solr\client\java\solrj\test\org\apache\solr\client\solrj\Lar
geVolumeTest
Yonik Seeley wrote:
On 9/19/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
Yonik Seeley wrote:
ant test from the command line is currently failing.
compileTests:
[mkdir] Created dir: F:\code\solr\build\tests
[javac] Compiling 66 source files to F:\code\solr\build\tests
[ja
In SOLR-133, we switched from XPP to the stax parser. We left the old
Xpp update handler just in case.
It should not be included it in the 1.3 release. Are we ready to drop
it now? (obviously no hurry)
ryan
Would it be appropriate to exclude this test, since a test that fails
every night is like the boy who cried wolf? At least until it's worked
out -- I'm not really familiar with the setup on the nightly build box.
+1! Never-working tests are worse than no tests.
I agree crying wolf is BAD BA
I could build one CommonsHttpSolrServer for each query, or I could build
just one, put it in a singleton and reuse it.
either way. Solrj uses MultiThreadedHttpConnectionManager.
SolrJ I'm using is dated 2007-09-24 (downloaded from hudson), httpclient
libs used is 3.1 (the very one than ca
Check my last comment on SOLR-215
which should not be an indication that the code in question will not
function correctly. Also, there isn't a peep of warning in CHANGES.txt
I was waiting for SOLR-360 to add the CHANGES.txt for multi-core related
things. You are right, the deprecated A
being offline and out of hte loop for a few days has left me a little
confused as to what exactly the imcompatibility is ... could someone open
an issue summarizing the problem and mark it fix for 1.3 .. that way we'll
have a reminder to either get a fix in, or document the hell out of it as
but Is CommonsHttpSolrServer thread-safe?
It better be! To the best of my knowledge, it is. If you have any
troubles with it, we need to fix them.
the underlying connections are thread safe:
http://jakarta.apache.org/httpcomponents/httpclient-3.x/threading.html
we use MultiThreadedHttpCo
I can't help but wonder if it would make more sense to replace this with
something like "SolrCore.Initializable" ... you can get a SolrConfig from
a SolrCore, but you can't get a SolrCore from a SolrConfig.
yes, that sounds like a good idea.
The one (potential) issue is that the core may not b
HH... even better, SolrConfig could be changed to implement
SolrCoreAware, and all of the hard work could be implmented with the
addition below to SolrConfig (and all SolrCore has to do is call
solrConfig.tellAboutCore(this)) ...
private List needToTell = new List()
private Sol
Bill Au wrote:
Subject says it all.
+1
I see a couple options
1. Do the processing client side -- this may be your simplest and will
work with whatever version of solr you are using
2. If you are willing to muck around with some poorly documented, not
totally stable (as in fixed API) bleeding edge stuff, you could do what
you are
[
https://issues.apache.org/jira/browse/SOLR-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley reassigned SOLR-408:
--
Assignee: Ryan McKinley
> PingRequestHandler
> --
>
>
[
https://issues.apache.org/jira/browse/SOLR-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541151
]
Ryan McKinley commented on SOLR-408:
agreed - i'll post a modified patch shortly
> PingReques
[
https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-139:
---
Fix Version/s: 1.3
Issue Type: New Feature (was: Improvement)
> Support updateable/modifia
[
https://issues.apache.org/jira/browse/SOLR-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-272.
Resolution: Fixed
> SolrDocument performance test
[
https://issues.apache.org/jira/browse/SOLR-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-389.
Resolution: Fixed
commited a while back. Thanks Grant
> RequestHandlerBase javadocs improvem
[
https://issues.apache.org/jira/browse/SOLR-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-408:
---
Attachment: SOLR-408-PingRequestHandler.patch
updated your patch to use its own parameters for the
[
https://issues.apache.org/jira/browse/SOLR-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-408.
Resolution: Fixed
Fix Version/s: 1.3
thanks Karsten
> PingRequestHand
[
https://issues.apache.org/jira/browse/SOLR-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-335.
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Ryan McKinley
SOLR-408 adds a
[
https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-281:
---
Attachment: SOLR-281-SearchComponents.patch
Here is an updated version of your patch that converts the
[
https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-176.
Resolution: Fixed
Committed as part of SOLR-281
> Add detailed timing data to query response out
[
https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-281:
---
Component/s: search
Fix Version/s: 1.3
Assignee: Ryan McKinley
Affects
[
https://issues.apache.org/jira/browse/SOLR-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-110.
Resolution: Fixed
SOLR-281 moves common search operation into reusable 'components'
&g
501 - 600 of 1806 matches
Mail list logo
