[
https://issues.apache.org/jira/browse/SOLR-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-2042:
Attachment: SOLR-2042-no-stax.patch
Since trunk is on java 1.6, we do not any stax dependencies.
Remove StAX libraries from trunk (java6)
Key: SOLR-2054
URL: https://issues.apache.org/jira/browse/SOLR-2054
Project: Solr
Issue Type: Task
Reporter: Ryan McKinley
Priority:
[
https://issues.apache.org/jira/browse/SOLR-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899748#action_12899748
]
Ryan McKinley commented on SOLR-2054:
-
I removed the stax libs from the pom.xml in
[
https://issues.apache.org/jira/browse/SOLR-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-2054:
Fix Version/s: 4.0
Remove StAX libraries from trunk (java6)
[
https://issues.apache.org/jira/browse/SOLR-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathias Walter updated SOLR-1395:
-
Attachment: front-end.log
back-end.log
I ported the patch to Solr 3.1 and Katta
[
https://issues.apache.org/jira/browse/SOLR-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899788#action_12899788
]
Mathias Walter edited comment on SOLR-1395 at 8/18/10 4:59 AM:
---
[
https://issues.apache.org/jira/browse/SOLR-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899788#action_12899788
]
Mathias Walter edited comment on SOLR-1395 at 8/18/10 5:00 AM:
---
CLONE -woodstox dependency in maven solrj has wrong groupId
---
Key: SOLR-2055
URL: https://issues.apache.org/jira/browse/SOLR-2055
Project: Solr
Issue Type: Bug
Components:
[
https://issues.apache.org/jira/browse/SOLR-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Annies updated SOLR-2055:
---
Affects Version/s: 1.4.1
(was: 1.4)
Fix Version/s:
[
https://issues.apache.org/jira/browse/SOLR-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899812#action_12899812
]
Robert Muir commented on SOLR-1860:
---
committed this as rev 986612 (and 3x rev 986615).
This is the issue:
https://issues.apache.org/jira/browse/LUCENE-2574
It was a low-level optimization on how we copy bytes between files.
The first commit (on Jul 30) introduced the corruption bug, and then
it took a few days (until Aug 4) to find fix it. Any index built
using Lucene's
[
https://issues.apache.org/jira/browse/LUCENE-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-2606:
Attachment: LUCENE-2606.patch
attached is another iteration:
* because the Query stores
[
https://issues.apache.org/jira/browse/LUCENE-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899822#action_12899822
]
Uwe Schindler commented on LUCENE-2606:
---
Looks good! The thing was broken in 3.x and
Hi,
I have noticed that the JCC 2.6 has a env.classpath and also a method
_addClassPath()
When I use _addClassPath, jvm.classpath shows the new change -- can we
use this method to add classpath when VM is already running? Will it
stay, the _name looks like is not meant to be public?
Thanks,
[
https://issues.apache.org/jira/browse/SOLR-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll updated SOLR-2053:
--
Attachment: SOLR-2053.patch
Patch that hooks in comparator specification to Solr Lucene
Anyone have opinions on dealing with combined issues in JIRA. By this, I
mean, issues that involve both changes to Lucene and Solr. For instance, I'm
doing some work on the spell checker right now, which I am then immediately
implementing in the SpellCheckComponent. It seems silly to first
Hi folks,
What is the proper way to retrieve a string field from lucene in trunk? I'm
specifically looking for the equivalent of:
String[] fieldValues = FieldCache.DEFAULT.getStrings(reader,fieldName);
String actualValue = fieldValues[luceneID-docBase];
The getStrings() method seems to have
[
https://issues.apache.org/jira/browse/SOLR-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll resolved SOLR-2053.
---
Fix Version/s: 3.1
4.0
Resolution: Fixed
Committed revision 986707.
Check out getTerms and getTermsIndex
-Yonik
http://www.lucidimagination.com
On Wed, Aug 18, 2010 at 10:49 AM, karl.wri...@nokia.com wrote:
Hi folks,
What is the proper way to retrieve a string field from lucene in trunk? I’m
specifically looking for the equivalent of:
String[]
On Wed, Aug 18, 2010 at 10:48 AM, Grant Ingersoll gsing...@apache.org wrote:
Anyone have opinions on dealing with combined issues in JIRA. By this, I
mean, issues that involve both changes to Lucene and Solr.
It often makes sense - we've had a lot of patches that go across both already.
Exactly. getTerms() returns a DocTerms, which has this:
/** The BytesRef argument must not be null; the method
* returns the same BytesRef, or an empty (length=0)
* BytesRef if the doc did not have this field or was
* deleted. */
public abstract BytesRef getTerm(int
Karl,
I believe one may pass an empty BytesRef in, and the values will be
set within the getTerm method.
On Wed, Aug 18, 2010 at 8:18 AM, karl.wri...@nokia.com wrote:
Exactly. getTerms() returns a DocTerms, which has this:
/** The BytesRef argument must not be null; the method
*
If you are correct, the comment is certainly incorrect, since it implies that
the SAME BytesRef is returned as you pass in.
Karl
-Original Message-
From: ext Jason Rutherglen [mailto:jason.rutherg...@gmail.com]
Sent: Wednesday, August 18, 2010 11:27 AM
To: dev@lucene.apache.org
Cc:
Passing in new BytesRef(), I always get back an empty string. So clearly the
comment *is* correct, and neither you nor I know how to do this properly. ;-)
Any other suggestions?
Karl
-Original Message-
From: Wright Karl (Nokia-MS/Cambridge)
Sent: Wednesday, August 18, 2010 11:28 AM
On Wed, Aug 18, 2010 at 11:28 AM, karl.wri...@nokia.com wrote:
If you are correct, the comment is certainly incorrect, since it implies that
the SAME BytesRef is returned as you pass in.
Yes, that's correct. BytesRef is mutable. You pass in an instance,
and the value is set and the same
On Wed, Aug 18, 2010 at 12:03 PM, Yonik Seeley
yo...@lucidimagination.com wrote:
On Wed, Aug 18, 2010 at 11:28 AM, karl.wri...@nokia.com wrote:
If you are correct, the comment is certainly incorrect, since it implies
that the SAME BytesRef is returned as you pass in.
Yes, that's correct.
Also note that the MIGRATE.txt in the lucene subdir should cover this.
Mike
Sent from my iPad
On Aug 18, 2010, at 11:26 AM, Jason Rutherglen jason.rutherg...@gmail.com
wrote:
Karl,
I believe one may pass an empty BytesRef in, and the values will be
set within the getTerm method.
On
[
https://issues.apache.org/jira/browse/SOLR-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi resolved SOLR-2049.
--
Assignee: Koji Sekiguchi
Resolution: Fixed
trunk: Committed revision 986773.
branch_3x:
Thanks, didn't think to look there.
Unfortunately I'm still getting back empty strings - and this is for a required
field. So something isn't right...
Maybe I'll pester Simon. ;-)
Karl
-Original Message-
From: ext Michael McCandless [mailto:luc...@mikemccandless.com]
Sent: Wednesday,
[
https://issues.apache.org/jira/browse/SOLR-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-1881.
Fix Version/s: 4.0
(was: Next)
Resolution: Fixed
SearchHandler
pom files need to include velocity reference
Key: SOLR-2056
URL: https://issues.apache.org/jira/browse/SOLR-2056
Project: Solr
Issue Type: Bug
Affects Versions: 3.1, 4.0
Reporter:
[
https://issues.apache.org/jira/browse/SOLR-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-2056.
-
Resolution: Fixed
pom files need to include velocity reference
[
https://issues.apache.org/jira/browse/SOLR-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899945#action_12899945
]
Ryan McKinley commented on SOLR-2055:
-
isn't this the same as SOLR-2042?
CLONE
This field was *not* indexed, just stored. That seems to have been the
problem. Not sure why it must be indexed to be retrievable, but clearly it
does.
Karl
-Original Message-
From: ext Michael McCandless [mailto:luc...@mikemccandless.com]
Sent: Wednesday, August 18, 2010 2:28 PM
OK, that's good you got to the bottom of it.
This is (for better or worse) how FieldCache works. It uninverts the
requested field to reconstruct the forward index (mapping docID -
value), so the field must be indexed (and every field must have a
single token/value).
I agree it's odd... and
[
https://issues.apache.org/jira/browse/SOLR-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899980#action_12899980
]
Ryan McKinley commented on SOLR-2042:
-
interesting -- i wonder if you have to do
[
https://issues.apache.org/jira/browse/SOLR-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899984#action_12899984
]
Ryan McKinley commented on SOLR-2054:
-
In SOLR-2042, yonik points out:
| We could
I think I would prefer to just be able to refer to Lucene issues from time
to time in Solr's CHANGES.txt file and obviously, the patch would contain
the fix across the source. Thoughts?
I would appreciate creating two issues and use one only for reference
and link it by the one which
Hi all,
I was digging into what exactly expungeDeletes means, and what it would during
during an optimize/ call. From my reading of the docs:
http://lucene.apache.org/java/2_9_3/api/core/org/apache/lucene/index/IndexWriter.html#expungeDeletes()
we should either do an optimize or an
[
https://issues.apache.org/jira/browse/LUCENE-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12900028#action_12900028
]
Robert Muir commented on LUCENE-2606:
-
bq. Looks good! The thing was broken in 3.x and
On Wed, Aug 18, 2010 at 4:46 PM, Eric Pugh
ep...@opensourceconnections.com wrote:
So would it make sense to update the wiki page to say the expungeDeletes only
makes sense as a commit parameter, not an optimize parameter?
Perhaps a better way of putting it is that expungeDeletes on an
optimize
Okay, I tried to clarify wiki page.
Eric
On Aug 18, 2010, at 4:56 PM, Yonik Seeley wrote:
On Wed, Aug 18, 2010 at 4:46 PM, Eric Pugh
ep...@opensourceconnections.com wrote:
So would it make sense to update the wiki page to say the expungeDeletes
only makes sense as a commit parameter, not
[
https://issues.apache.org/jira/browse/SOLR-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12900076#action_12900076
]
Robert Muir commented on SOLR-2034:
---
Thanks Ryan, I'll wait a few days before committing
[
https://issues.apache.org/jira/browse/LUCENE-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-2514:
Attachment: LUCENE-2514_collatedrange.patch
just checkpointing progress, here's my latest patch.
[
https://issues.apache.org/jira/browse/SOLR-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer updated SOLR-2010:
-
Attachment: SOLR-2010.txt
Second version of patch. Updated to trunk rev #986945.
Adds support for
DataImportHandler never calls UpdateRequestProcessor.finish()
-
Key: SOLR-2057
URL: https://issues.apache.org/jira/browse/SOLR-2057
Project: Solr
Issue Type: Bug
[
https://issues.apache.org/jira/browse/SOLR-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Drew Farris updated SOLR-2057:
--
Attachment: SOLR-2057.patch
This patch against branch_3x adds a finish() method to SolrWriter which in
[
https://issues.apache.org/jira/browse/SOLR-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12900155#action_12900155
]
Drew Farris commented on SOLR-2055:
---
bq. In case there is another 1.4.x release I'd like a
Isn't DUH deprecated by now? Should anyone use it? Does it still work?
On Wed, Aug 18, 2010 at 2:15 PM, Eric Pugh
ep...@opensourceconnections.com wrote:
Okay, I tried to clarify wiki page.
Eric
On Aug 18, 2010, at 4:56 PM, Yonik Seeley wrote:
On Wed, Aug 18, 2010 at 4:46 PM, Eric Pugh
49 matches
Mail list logo
