[
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012353#comment-13012353
]
Uwe Schindler commented on LUCENE-1768:
---
{quote}
-merge DateTools with a new Numeri
[
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012352#comment-13012352
]
Uwe Schindler commented on LUCENE-1768:
---
{quote}
- I remember the old date query, u
[
https://issues.apache.org/jira/browse/LUCENE-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012331#comment-13012331
]
Phillipe Ramalho commented on LUCENE-2979:
--
{quote}
Don't forget to describe how
>
> And I'm still on the fence - _explain_ alone does not justify a whole
> new syntax IMO... so we may need more usecase examples to figure out
> what problem we're actually trying to solve.
>
The key use case I am thinking of is an easy way to add a value to the
the response. In SQL:
SELECT na
[
https://issues.apache.org/jira/browse/SOLR-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012327#comment-13012327
]
Ryan McKinley commented on SOLR-2444:
-
That seems fine -- if you don't want people to a
On Mon, Mar 28, 2011 at 9:36 PM, Chris Hostetter
wrote:
>
> : On IRC, yonik suggested that the explain format should mimic follow what
> : the debugQuery parameter would use.
> :
> : I'm don't really agree -- long term I would even suggest dropping the
> : explain section from debug and letting yo
[
https://issues.apache.org/jira/browse/SOLR-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012323#comment-13012323
]
Yonik Seeley commented on SOLR-2444:
In the case where some fields may come from a DB,
[
https://issues.apache.org/jira/browse/SOLR-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012320#comment-13012320
]
Ryan McKinley commented on SOLR-2444:
-
I think it makes sense because it is the place y
[
https://issues.apache.org/jira/browse/SOLR-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012317#comment-13012317
]
Yonik Seeley commented on SOLR-2444:
It's not even clear to me why invoking a transform
On Mon, Mar 28, 2011 at 9:36 PM, Chris Hostetter
wrote:
>
> : On IRC, yonik suggested that the explain format should mimic follow what
> : the debugQuery parameter would use.
> :
> : I'm don't really agree -- long term I would even suggest dropping the
> : explain section from debug and letting yo
[
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012314#comment-13012314
]
Adriano Crestani commented on LUCENE-1768:
--
Hi Vinicius,
Nice summary! There is
: On IRC, yonik suggested that the explain format should mimic follow what
: the debugQuery parameter would use.
:
: I'm don't really agree -- long term I would even suggest dropping the
: explain section from debug and letting you specify it as an inline
: parameter.
those seem like orthogin
[
https://issues.apache.org/jira/browse/SOLR-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012298#comment-13012298
]
Koji Sekiguchi commented on SOLR-2445:
--
bq. there's no requirement that a handler name
[
https://issues.apache.org/jira/browse/SOLR-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012290#comment-13012290
]
Koji Sekiguchi commented on SOLR-2445:
--
bq. If the problem here is that form.jsp defau
[
https://issues.apache.org/jira/browse/SOLR-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man reopened SOLR-2445:
wait a minute ... there's no requirement that a handler named "standard" exist,
nor is there any reason why sol
: > Optimizing cases where filters might be more expensive than the main query
;-)
: But you must have a real use case... that inspired this idea? Where
: are apps/Solr "typically" using such expensive filters?
i have no idea what usecase prompted yonik to start thinking about this,
but the f
[
https://issues.apache.org/jira/browse/LUCENE-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Drapkin updated LUCENE-2997:
---
Description:
I recently needed to deploy payloads for my search system and ran into a small
[
https://issues.apache.org/jira/browse/LUCENE-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Drapkin updated LUCENE-2997:
---
Attachment: PayloadQueryParser.java
PayloadQueryParser implementation.
> PayloadQueryParser
PayloadQueryParser addition
---
Key: LUCENE-2997
URL: https://issues.apache.org/jira/browse/LUCENE-2997
Project: Lucene - Java
Issue Type: New Feature
Components: contrib/*, QueryParser
Affects Versions:
> Last comment: I know we've intentionally bundled slf4j-jdk14-1.5.5.jar in the
> war to help newbies get up and running. But I find myself re-packaging the
> war for every customer when adapting to their choice of logger framework,
> which is counter-productive. Would it not be sufficient to ha
My comments, mostly minor:
apache-solr-3.1.0.zip:
* README.TXT - Mixes Unix- and Windows-style syntaxes without further comments
Propose to change e.g. %JAVA_HOME%\bin -> $JAVA_HOME/bin to be consistent and
add a comment about Windows
* CHANGES.TXT - The headline "Upgrading from Solr 1.4" shoul
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/6454/
1 tests failed.
REGRESSION: org.apache.lucene.collation.TestCollationKeyAnalyzer.testThreadSafe
Error Message:
Java heap space
Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf
I would rather not rebuild for L-2996. This issue has a known workaround. As
for the sources issue that Andi brought up, it never effected 3.1 b/c it
doesn't have the validation stuff.
I'd like to stick w/ the artifacts we have.
On Mar 28, 2011, at 11:33 AM, Shai Erera wrote:
> If you're ta
Update: I switched to the newest IBM JRE I have available, but the test
still fails with that seed.
Shai
On Mon, Mar 28, 2011 at 5:20 PM, Robert Muir wrote:
> FYI this is a relatively new test, and I think its a bug in IBM's jre.
> I found similar problems in ICU and i know IBM JRE's intl impl
Shai,
This has also been failing on trunk, but I can't repro it, so it's
awesome you can!
Can you turn on IW's infoStream and get the failure to happen and post
the results?
I agree this is likely a CMS thing...
Mike
http://blog.mikemccandless.com
On Mon, Mar 28, 2011 at 8:15 AM, Shai Erera
[
https://issues.apache.org/jira/browse/LUCENE-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012116#comment-13012116
]
Shai Erera commented on LUCENE-2996:
Committed revision 1086275 (3x).
Committed revis
[
https://issues.apache.org/jira/browse/SOLR-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi resolved SOLR-2445.
--
Resolution: Fixed
trunk: Committed revision 1086276.
3x: Committed revision 1086289.
> unknown
OK, sorry, I misunderstood the thread.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Robert Muir [mailto:rcm...@gmail.com]
> Sent: Monday, March 28, 2011 5:05 PM
> To: dev@lucene.apache.org
> Subject:
If you're talking about LUCENE-2996, then note that I haven't checked in the
code yet. If you're going to rebuild the artifacts off of
branches/lucene_solr_3_1, I can check in the code there now.
Shai
On Mon, Mar 28, 2011 at 5:04 PM, Robert Muir wrote:
> On Mon, Mar 28, 2011 at 10:54 AM, Uwe Sc
FYI this is a relatively new test, and I think its a bug in IBM's jre.
I found similar problems in ICU and i know IBM JRE's intl impl is
different than sun's (maybe a newer icu version?)
I worked around these in the icu collation tests, and we might have to
do the same here... we can't use "totall
On Mon, Mar 28, 2011 at 10:54 AM, Uwe Schindler wrote:
> Hi,
>
> If we we have to rebuild the artifacts, should we add Shai/Mike's
> addIndexes() fix, too?
>
3.1 branch is fine with regards to this issue, thats why I raised my
question... it seems only the 3.1 release branch was "fixed" for this
[
https://issues.apache.org/jira/browse/SOLR-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-2445:
-
Fix Version/s: 4.0
3.2
Assignee: Koji Sekiguchi
Will commit soon.
> u
Hi,
If we we have to rebuild the artifacts, should we add Shai/Mike's
addIndexes() fix, too?
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Grant Ingersoll [mailto:gsing...@apache.org]
> Sent: Mond
My machine is hot at picking seeds today :).
[junit]
[junit] junit.framework.AssertionFailedError:
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1076)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.
[
https://issues.apache.org/jira/browse/LUCENE-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012069#comment-13012069
]
Simon Willnauer commented on LUCENE-2573:
-
bq. How come we lost 'assert !buffered
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/6446/
1 tests failed.
REGRESSION:
org.apache.lucene.index.TestIndexWriterMergePolicy.testMaxBufferedDocsChange
Error Message:
docCount=10 lowerBound=10 i=5 segmentCount=11 index=_1e(3.2):Cv1081
_1z(3.2):Cv1064 _2k(3.2):Cv14
[
https://issues.apache.org/jira/browse/SOLR-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012047#comment-13012047
]
Vadim Kisselmann commented on SOLR-1144:
I have Solr running on one master and two
[
https://issues.apache.org/jira/browse/SOLR-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-2436:
-
Attachment: SOLR-2436.patch
Hi Tommaso,
bq. However I think it should be good if it was possible
[
https://issues.apache.org/jira/browse/LUCENE-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-2996:
---
Attachment: LUCENE-2996.patch
bq. shouldn't the test use newIndexWriterConfig(TEST_VERSION_CURRENT,
I don't think it is lost, it's likely my mistake in adding a top level
common-build for the validation stuff. We can change it out.
On Mar 28, 2011, at 8:27 AM, Robert Muir wrote:
> the real question is: why is this fixed only in the 3.1 branch?
>
> how did our 3.1 branch and 3.x/trunk get so
[
https://issues.apache.org/jira/browse/LUCENE-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012028#comment-13012028
]
Simon Willnauer commented on LUCENE-2996:
-
Shai, patch looks ok.
shouldn't the t
Please, as asked previously, use the users list for this type of question. This
list is intended for developers working on the Lucene and Solr code.
The correct address is: solr-u...@lucene.apache.org
See: http://lucene.apache.org/solr/mailing_lists.html
Best
Erick
On Mon, Mar 28, 2011 at 3:51
[
https://issues.apache.org/jira/browse/LUCENE-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-2996:
---
Attachment: LUCENE-2996.patch
Patch adds a test to TestAddIndexes and the trivial fix to IndexWriter
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/6456/
15 tests failed.
REGRESSION: org.apache.lucene.index.TestIndexReaderReopen.testThreadSafety
Error Message:
org/apache/lucene/util/LuceneTestCase$TwoLongs
Stack Trace:
java.lang.NoClassDefFoundError: org/apache/lucene
the real question is: why is this fixed only in the 3.1 branch?
how did our 3.1 branch and 3.x/trunk get so different? I don't like
that any work done to get 3.1 out the door is going to be "lost" and
have to be re-done.
On Sun, Mar 27, 2011 at 5:26 PM, Andi Vajda wrote:
>
> Hi,
>
> It seems t
Turns out this is not easily reproducible. While I am able to reproduce it
*many times* on my machine, it's not *always*. I did notice a strange
behavior -- when the test fails, the stack trace points to what seems to be
an incorrect line. I don't know why, even though I 'ant clean' and 'svn up'
et
Renaming to *-ASL on 3x and trunk (as the file indicates it's ASL) resolve
the problem.
Committed to 3x and trunk.
Shai
On Mon, Mar 28, 2011 at 10:57 AM, Shai Erera wrote:
> Hi
>
> When I run 'ant validate-lucene' on the latest 3x, I get this:
>
> Starting on dir: lucene\lib
> WARNING: There m
http://wiki.apache.org/solr/UpdateXmlMessages#Updating_a_Data_Record_via_curl
2011/3/28 Deepak Singh :
> how to update fields of existing document through http or curl methods.
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@lucene
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/6440/
1 tests failed.
REGRESSION: org.apache.lucene.collation.TestCollationKeyAnalyzer.testThreadSafe
Error Message:
Java heap space
Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf
how to update fields of existing document through http or curl methods.
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/6438/
1 tests failed.
REGRESSION: org.apache.lucene.collation.TestCollationKeyAnalyzer.testThreadSafe
Error Message:
Java heap space
Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf
Hi
When I run 'ant validate-lucene' on the latest 3x, I get this:
Starting on dir: lucene\lib
WARNING: There may be missing NOTICE files in: lucene\lib. Note, not all
files require a NOTICE. Jar file count: 3 Notice Count: 2
Invalid license: LICENSE for ant-junit-LICENSE.txt
Exception in thread
i just to do a search in both database and documents(pdf,doc etc).
how to make schema for both database and documents fields.
i m unable to do.
53 matches
Mail list logo
