[jira] Created: (LUCENE-1872) Improve javadocs for Numeric*
Improve javadocs for Numeric* - Key: LUCENE-1872 URL: https://issues.apache.org/jira/browse/LUCENE-1872 Project: Lucene - Java Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Priority: Minor Fix For: 2.9 I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749097#action_12749097 ] Uwe Schindler commented on LUCENE-1872: --- This is correct (first part), you can add a field more than once and it really works (there is a test about that). The results are the same like with a normal range query (so the trie terms do not interfere between each other). About the second one: Sorting is not different from other numeric multi-value fields (in contrast to StringIndex where only one value/doc is allowed). The univerter assigns a value to each document. As it overrides values previously assigned to the document when iterating over all terms in the field, the last term would be the one saved in the FieldCache. So you would sort against the largest value per doc (because the smaller values are overridden by the larger ones in the field cache). > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Issue Comment Edited: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749097#action_12749097 ] Uwe Schindler edited comment on LUCENE-1872 at 8/29/09 2:40 AM: This is correct (first part), you can add a field more than once and it really works (there is a test about that: TestMultiValuedNumericRangeQuery). The results are the same like with a normal range query (so the trie terms do not interfere between each other). See SOLR-1322 I think your sentence is a little bit complicated. It would hit all documents in the range, where at least one of the values of a multi-valued doc is in the range. About the second one: Sorting is not different from other numeric multi-value fields (in contrast to StringIndex where only one value/doc is allowed). The univerter assigns a value to each document. As it overrides values previously assigned to the document when iterating over all terms in the field, the last term would be the one saved in the FieldCache. So you would sort against the largest value per doc (because the smaller values are overridden by the larger ones in the field cache). was (Author: thetaphi): This is correct (first part), you can add a field more than once and it really works (there is a test about that). The results are the same like with a normal range query (so the trie terms do not interfere between each other). About the second one: Sorting is not different from other numeric multi-value fields (in contrast to StringIndex where only one value/doc is allowed). The univerter assigns a value to each document. As it overrides values previously assigned to the document when iterating over all terms in the field, the last term would be the one saved in the FieldCache. So you would sort against the largest value per doc (because the smaller values are overridden by the larger ones in the field cache). > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749100#action_12749100 ] Michael McCandless commented on LUCENE-1872: bq. About the second one: Sorting is not different from other numeric multi-value fields (in contrast to StringIndex where only one value/doc is allowed). The univerter assigns a value to each document. As it overrides values previously assigned to the document when iterating over all terms in the field, the last term would be the one saved in the FieldCache. So you would sort against the largest value per doc (because the smaller values are overridden by the larger ones in the field cache). Ahh right. I'm confused on why it's the "largest" value? EG if I add 4, 17, 10 as a NumericField "x" on my doc, when I then try to sort, wouldn't 10 "win" since it was added last to the document? > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1872) Improve javadocs for Numeric*
[
https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749102#action_12749102
]
Uwe Schindler commented on LUCENE-1872:
---
bq. I'm confused on why it's the "largest" value? EG if I add 4, 17, 10 as a
NumericField "x" on my doc, when I then try to sort, wouldn't 10 "win" since it
was added last to the document?
Because of the uninverter. It iterates over all terms, starting from the lowest
one in the field. When he comes to term 4, it would add it to the field cache
at the document's position. The same with 10 and then 17. Because the TermEnum
lists 17 at last, it would win:
{code}
long[] retArray = null;
TermDocs termDocs = reader.termDocs();
TermEnum termEnum = reader.terms (new Term(field));
try {
do {
Term term = termEnum.term();
if (term==null || term.field() != field) break;
long termval = parser.parseLong(term.text());
if (retArray == null) // late init
retArray = new long[reader.maxDoc()];
termDocs.seek (termEnum);
while (termDocs.next()) {
retArray[termDocs.doc()] = termval;
}
} while (termEnum.next());
} catch (StopFillCacheException stop) {
} finally {
termDocs.close();
termEnum.close();
}
if (retArray == null) // no values
retArray = new long[reader.maxDoc()];
{code}
> Improve javadocs for Numeric*
> -
>
> Key: LUCENE-1872
> URL: https://issues.apache.org/jira/browse/LUCENE-1872
> Project: Lucene - Java
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 2.9
>
>
> I'm working on improving Numeric* javadocs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749095#action_12749095 ] Michael McCandless commented on LUCENE-1872: Can someone confirm that this is technically accurate (I've added it to the javadoc for NumericField): bq. You may add the same field name as a NumericField to the same document more than once. Range querying and filtering will be the logical OR of all values, and sorting will sort according to the first value added. > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749106#action_12749106 ] Michael McCandless commented on LUCENE-1872: bq. Because of the uninverter. Ahh right! I think it's best to document that the effect of sorting is undefined/not guaranteed, but filtering/searching by range is defined. > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749107#action_12749107 ] Uwe Schindler commented on LUCENE-1872: --- Thank you at all for looking after the documentation! A native speaker is always better than my "frankish" English (as my colleague call it). :) > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749111#action_12749111 ] Michael McCandless commented on LUCENE-1872: bq. Thank you at all for looking after the documentation! A native speaker is always better than my "frankish" English (as my colleague call it). No problem! This is how open source works :) It's great. > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-1872: --- Attachment: LUCENE-1872.patch Only javadoc fixes, mostly for Numeric* but also some small fixes to a few other classes. > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > Attachments: LUCENE-1872.patch > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749113#action_12749113 ] Uwe Schindler commented on LUCENE-1872: --- Will we mark it as experimental or not? In some classes you remove the experimental warning, in others not. I will review it more detailed later! By the way, I also reviewd the LIA chapter and have also seen the reference to DateTools (will send you my updates soon). ate to a String with a special date resolution and then convertin back to numeric is somehow ineffective. When indexing only hour resolution, I would take Date.getTime() / 3600L / 1000L. > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > Attachments: LUCENE-1872.patch > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749114#action_12749114 ] Uwe Schindler commented on LUCENE-1872: --- Maybe you could copy some of your explanations also to NumericTokenStream, e.g. the example. In the original, both classes had similar introduction texts. > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > Attachments: LUCENE-1872.patch > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749117#action_12749117 ] Michael McCandless commented on LUCENE-1872: bq. Will we mark it as experimental or not? Yes, I think we should keep the experimental warning. I didn't mean to remove any -- I'll make sure they're all still there. bq. By the way, I also reviewd the LIA chapter and have also seen the reference to DateTools (will send you my updates soon) Excellent, thanks! bq. ate to a String with a special date resolution and then convertin back to numeric is somehow ineffective. When indexing only hour resolution, I would take Date.getTime() / 3600L / 1000L. True, and that'll work for DAY as well, but not for MONTH / YEAR resolution. bq. Maybe you could copy some of your explanations also to NumericTokenStream, e.g. the example. In the original, both classes had similar introduction texts. OK I'll update NumericTokenStream too. > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > Attachments: LUCENE-1872.patch > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-1872: --- Attachment: LUCENE-1872.patch New rev. As far as I can tell, I didn't lose any of the experimental warnings -- Uwe where did you see that? I worked on NumericTokenStream's javadocs too. Finally, I removed reference to DateTools entirely and suggested either quantizing by dividing getTime()'s returned result, or, using Date's getters (getYear, getMonth, etc.) to construct a numeric value. > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > Attachments: LUCENE-1872.patch, LUCENE-1872.patch > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749127#action_12749127 ] Uwe Schindler commented on LUCENE-1872: --- bq. As far as I can tell, I didn't lose any of the experimental warnings - Uwe where did you see that? My fault. I did not see that you moved the warning to the top in NumericRangeQuery. Looks good. > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > Attachments: LUCENE-1872.patch, LUCENE-1872.patch > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1872) Improve javadocs for Numeric*
[
https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749132#action_12749132
]
Uwe Schindler commented on LUCENE-1872:
---
One small thing (I found this also in the LIA chapter):
"Trie" is the whole "prefix tree". So "trie" means the whole list of different
precision terms for one numeric value. You have this explanation which suggests
one trie is one term:
{code}
+ * Within lucene, each numeric value is indexed as
+ * multiple encoded terms representing larger and larger
+ * pre-defined brackets called tries. The step
+ * size between each successive trie is called the
+ * precisionStep in this API. Smaller
{code}
> Improve javadocs for Numeric*
> -
>
> Key: LUCENE-1872
> URL: https://issues.apache.org/jira/browse/LUCENE-1872
> Project: Lucene - Java
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 2.9
>
> Attachments: LUCENE-1872.patch, LUCENE-1872.patch
>
>
> I'm working on improving Numeric* javadocs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Issue Comment Edited: (LUCENE-1872) Improve javadocs for Numeric*
[
https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749132#action_12749132
]
Uwe Schindler edited comment on LUCENE-1872 at 8/29/09 6:39 AM:
One small thing (I found this also in the LIA chapter):
"Trie" is the whole "prefix tree". So "trie" means the whole list of different
precision terms for one numeric value. You have this explanation which suggests
one trie is one term:
{code}
+ * Within lucene, each numeric value is indexed as
+ * multiple encoded terms representing larger and larger
+ * pre-defined brackets called tries. The step
+ * size between each successive trie is called the
+ * precisionStep in this API. Smaller
{code}
There should also be the explanation that the precStep is in "bits".
was (Author: thetaphi):
One small thing (I found this also in the LIA chapter):
"Trie" is the whole "prefix tree". So "trie" means the whole list of different
precision terms for one numeric value. You have this explanation which suggests
one trie is one term:
{code}
+ * Within lucene, each numeric value is indexed as
+ * multiple encoded terms representing larger and larger
+ * pre-defined brackets called tries. The step
+ * size between each successive trie is called the
+ * precisionStep in this API. Smaller
{code}
> Improve javadocs for Numeric*
> -
>
> Key: LUCENE-1872
> URL: https://issues.apache.org/jira/browse/LUCENE-1872
> Project: Lucene - Java
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 2.9
>
> Attachments: LUCENE-1872.patch, LUCENE-1872.patch
>
>
> I'm working on improving Numeric* javadocs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-1872: --- Attachment: LUCENE-1872.patch State that precSteps is "bits", and trie is the entire data structure. > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > Attachments: LUCENE-1872.patch, LUCENE-1872.patch, LUCENE-1872.patch > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749148#action_12749148 ] Michael McCandless commented on LUCENE-1872: bq. "Trie" is the whole "prefix tree". OK -- I tweaked NumericField to fix that. I'll fix LIA2's manuscript too... thanks! > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > Attachments: LUCENE-1872.patch, LUCENE-1872.patch, LUCENE-1872.patch > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Porting Java Lucene 2.9 to Lucene.Net (was: RE: Lucene 2.9 RC2 now available for testing)
Hi Folks, I have been following the expected release of Lucene.Net 2.9 for some weeks now, and about 2 weeks ago, just before RC1 was released, I grabbed the code off the trunk and started my initial port. Today, I compared what I have with what's in RC2, only 6 Java files changes -- this is good. My question is, I would prefer to track SVN commits to keep track of changes, vs. what I'm doing now. This will allow us to stay weeks behind a Java release vs. months or years as it is now. However, while I'm subscribed to SVN's commits mailing list, I'm not getting all those commits! For example, a commit made this past Friday, I never got an email for, while other commits I do. Any idea what maybe going on? I just sent another subscription request email to SVN commit, but I'm not sure if that will make any difference. Thanks. -- George -Original Message- From: Mark Miller [mailto:markrmil...@gmail.com] Sent: Friday, August 28, 2009 3:19 PM To: java-u...@lucene.apache.org Subject: Re: Lucene 2.9 RC2 now available for testing Mark Miller wrote: > > Download release candidate 1 here: > http://people.apache.org/~markrmiller/staging-area/lucene2.9rc2/ > In case anyone catches - yes that is a cut and paste typo - should read release candidate 2 (obvious, but just to cross my t's). -- - Mark http://www.lucidimagination.com - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: Porting Java Lucene 2.9 to Lucene.Net (was: RE: Lucene 2.9 RC2 now available for testing)
On Aug 29, 2009, at 10:58 AM, George Aroush wrote: Hi Folks, I have been following the expected release of Lucene.Net 2.9 for some weeks now, and about 2 weeks ago, just before RC1 was released, I grabbed the code off the trunk and started my initial port. Today, I compared what I have with what's in RC2, only 6 Java files changes -- this is good. My question is, I would prefer to track SVN commits to keep track of changes, vs. what I'm doing now. This will allow us to stay weeks behind a Java release vs. months or years as it is now. However, while I'm subscribed to SVN's commits mailing list, I'm not getting all those commits! For example, a commit made this past Friday, I never got an email for, while other commits I do. Any idea what maybe going on? There has been some flakiness with ASF servers, so maybe that is the reason? Are you using forwarding on people.a.o? - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
RE: Porting Java Lucene 2.9 to Lucene.Net (was: RE: Lucene 2.9 RC2 now available for testing)
> > while I'm subscribed to SVN's commits mailing list, I'm not getting > > all those commits! For example, a commit made this past Friday, I > > never got an email for, while other commits I do. Any idea what > > maybe going on? > > There has been some flakiness with ASF servers, so maybe that is the > reason? Are you using forwarding on people.a.o? No, I'm not using any forwarding. If the code, in the truck, goes through minimal changes for about 2 weeks, I should be fine (until when we figure out the mail issue). -- George - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: Porting Java Lucene 2.9 to Lucene.Net
George Aroush wrote: >>> while I'm subscribed to SVN's commits mailing list, I'm not getting >>> all those commits! For example, a commit made this past Friday, I >>> never got an email for, while other commits I do. Any idea what >>> maybe going on? >>> >> There has been some flakiness with ASF servers, so maybe that is the >> reason? Are you using forwarding on people.a.o? >> > > No, I'm not using any forwarding. > > If the code, in the truck, goes through minimal changes for about 2 weeks, I > should be fine (until when we figure out the mail issue). > > -- George > > > - > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > Have you noticed it happen more than the one time? I've seen similar odd drops on the reg mailing list rarely - a random reply will show up to an original email I never got. Didn't notice it happen enough to claim its anything but bad luck though ;) It makes me wonder what I've missed and not realized though. I'm not forwarding either. bq. If the code, in the truck, goes through minimal changes for about 2 weeks, It should be fairly stable over the next week - bug fixes, build issues, and doc are still fair game, but it should be quite contained and rarely involve code changes (knock on wood). When we unfreeze, there is likely to be rapid development moving towards 3.0 - we will branch off 2.9 before that though, and you will probably want to move from trunk to the branch. -- - Mark http://www.lucidimagination.com - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Created: (LUCENE-1873) Update site lucene-sandbox page
Update site lucene-sandbox page --- Key: LUCENE-1873 URL: https://issues.apache.org/jira/browse/LUCENE-1873 Project: Lucene - Java Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 2.9 The page has misleading/bad info. One thing I would like to do - but I won't attempt now (prob good for the modules issue) - is commit to one word - contrib or sandbox. I think sandbox should be purged myself. The current page says that the sandbox is kind of a rats nest with various early stage software that one day may make it into core - that info is outdated I think. We should replace it, and also specify how the back compat policy works in contrib eg each contrib can have its own policy, with the default being no policy. We should also drop the piece about being open to Lucene's committers and others - a bit outdated. We should also either include the other contribs, or change the wording to indicate that the list is only a sampling of the many contribs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Created: (LUCENE-1874) Further updates to the site scoring page
Further updates to the site scoring page
Key: LUCENE-1874
URL: https://issues.apache.org/jira/browse/LUCENE-1874
Project: Lucene - Java
Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
Fix For: 2.9
update the site scoring page - see Appendix:
{quote}
Class Diagrams
Karl Wettin's UML on the Wiki
{quote}
Karl's diagrams are outdated - I think this link should be pulled for 2.9
{quote}
Sequence Diagrams
FILL IN HERE. Volunteers?
{quote}
I think this should be pulled - I say put something like this as a task in JIRA
- not the published site docs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1862) duplicate package.html files in queryParser and analsysis.cn packages
[
https://issues.apache.org/jira/browse/LUCENE-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749171#action_12749171
]
Mark Miller commented on LUCENE-1862:
-
Anyone have any thoughts here? Any time I think about it, I just end up
thinking its best to leave it ... the javadoc itself (package descriptions)
still appears to come out correctly.
> duplicate package.html files in queryParser and analsysis.cn packages
> -
>
> Key: LUCENE-1862
> URL: https://issues.apache.org/jira/browse/LUCENE-1862
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Hoss Man
>Priority: Minor
> Fix For: 2.9
>
>
> These files conflict with eachother when building the javadocs. there can be
> only one (of each) ...
> {code}
> hoss...@brunner:~/lucene/java$ find src contrib -name package.html | perl
> -ple 's{.*src/java/}{}' | sort | uniq -c | grep -v " 1 "
>2 org/apache/lucene/analysis/cn/package.html
>2 org/apache/lucene/queryParser/package.html
> hoss...@brunner:~/lucene/java$ find src contrib -path
> \*queryParser/package.html
> src/java/org/apache/lucene/queryParser/package.html
> contrib/queryparser/src/java/org/apache/lucene/queryParser/package.html
> hoss...@brunner:~/lucene/java$ find src contrib -path \*cn/package.html
> contrib/analyzers/common/src/java/org/apache/lucene/analysis/cn/package.html
> contrib/analyzers/smartcn/src/java/org/apache/lucene/analysis/cn/package.html
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749179#action_12749179 ] Uwe Schindler commented on LUCENE-1872: --- I think this is fine now! Thanks. > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > Attachments: LUCENE-1872.patch, LUCENE-1872.patch, LUCENE-1872.patch > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
RE: Porting Java Lucene 2.9 to Lucene.Net
I have been watching SVN commits for about 2-3 weeks now (since the announcement that the trunk was going to be an RC) during this time, I have not received any email. It was emails from JIRA that hinted me at code checkin's. -- George -Original Message- From: Mark Miller [mailto:markrmil...@gmail.com] Sent: Saturday, August 29, 2009 11:56 AM To: java-dev@lucene.apache.org Subject: Re: Porting Java Lucene 2.9 to Lucene.Net George Aroush wrote: >>> while I'm subscribed to SVN's commits mailing list, I'm not getting >>> all those commits! For example, a commit made this past Friday, I >>> never got an email for, while other commits I do. Any idea what >>> maybe going on? >>> >> There has been some flakiness with ASF servers, so maybe that is the >> reason? Are you using forwarding on people.a.o? >> > > No, I'm not using any forwarding. > > If the code, in the truck, goes through minimal changes for about 2 weeks, I > should be fine (until when we figure out the mail issue). > > -- George > > > - > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > Have you noticed it happen more than the one time? I've seen similar odd drops on the reg mailing list rarely - a random reply will show up to an original email I never got. Didn't notice it happen enough to claim its anything but bad luck though ;) It makes me wonder what I've missed and not realized though. I'm not forwarding either. bq. If the code, in the truck, goes through minimal changes for about 2 weeks, It should be fairly stable over the next week - bug fixes, build issues, and doc are still fair game, but it should be quite contained and rarely involve code changes (knock on wood). When we unfreeze, there is likely to be rapid development moving towards 3.0 - we will branch off 2.9 before that though, and you will probably want to move from trunk to the branch. -- - Mark http://www.lucidimagination.com - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
RE: Porting Java Lucene 2.9 to Lucene.Net
I missed no commit mails the last days. Maybe they were declared as spam by your mail filter software? - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: George Aroush [mailto:geo...@aroush.net] > Sent: Saturday, August 29, 2009 10:36 PM > To: java-dev@lucene.apache.org > Subject: RE: Porting Java Lucene 2.9 to Lucene.Net > > I have been watching SVN commits for about 2-3 weeks now (since the > announcement that the trunk was going to be an RC) during this time, I > have > not received any email. It was emails from JIRA that hinted me at code > checkin's. > > -- George > > -Original Message- > From: Mark Miller [mailto:markrmil...@gmail.com] > Sent: Saturday, August 29, 2009 11:56 AM > To: java-dev@lucene.apache.org > Subject: Re: Porting Java Lucene 2.9 to Lucene.Net > > George Aroush wrote: > >>> while I'm subscribed to SVN's commits mailing list, I'm not getting > >>> all those commits! For example, a commit made this past Friday, I > >>> never got an email for, while other commits I do. Any idea what > >>> maybe going on? > >>> > >> There has been some flakiness with ASF servers, so maybe that is the > >> reason? Are you using forwarding on people.a.o? > >> > > > > No, I'm not using any forwarding. > > > > If the code, in the truck, goes through minimal changes for about 2 > weeks, > I > > should be fine (until when we figure out the mail issue). > > > > -- George > > > > > > - > > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > > > > Have you noticed it happen more than the one time? I've seen similar odd > drops on the reg mailing list rarely - a random reply will show up to an > original email I never got. Didn't notice it happen enough to claim its > anything but bad luck though ;) It makes me wonder what I've missed and > not realized though. I'm not forwarding either. > > bq. If the code, in the truck, goes through minimal changes for about 2 > weeks, > > It should be fairly stable over the next week - bug fixes, build issues, > and > doc are still fair game, but it should be quite contained and rarely > involve > code changes (knock on wood). When we unfreeze, there is likely to be > rapid > development moving towards 3.0 - we will branch off 2.9 before that > though, > and you will probably want to move from trunk to the branch. > > > -- > - Mark > > http://www.lucidimagination.com > > > > > - > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > > - > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Resolved: (LUCENE-1872) Improve javadocs for Numeric*
[ https://issues.apache.org/jira/browse/LUCENE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-1872. Resolution: Fixed OK thanks Uwe! > Improve javadocs for Numeric* > - > > Key: LUCENE-1872 > URL: https://issues.apache.org/jira/browse/LUCENE-1872 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 2.9 > > Attachments: LUCENE-1872.patch, LUCENE-1872.patch, LUCENE-1872.patch > > > I'm working on improving Numeric* javadocs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1862) duplicate package.html files in queryParser and analsysis.cn packages
[
https://issues.apache.org/jira/browse/LUCENE-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749192#action_12749192
]
Robert Muir commented on LUCENE-1862:
-
just stating the obvious, but for the analysis.cn, the problem is that I think
we want javadocs in
* analyzers javadocs jar
* smartcn javadocs jar
* javadocs-all target (which one?, this is causing the error)
it would be nice not to have the error, but also still have package.html in all
3. any ideas?
the whole point of the package.html in this case is to help users figure out
what all the chinese analysis options are...
> duplicate package.html files in queryParser and analsysis.cn packages
> -
>
> Key: LUCENE-1862
> URL: https://issues.apache.org/jira/browse/LUCENE-1862
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Hoss Man
>Priority: Minor
> Fix For: 2.9
>
>
> These files conflict with eachother when building the javadocs. there can be
> only one (of each) ...
> {code}
> hoss...@brunner:~/lucene/java$ find src contrib -name package.html | perl
> -ple 's{.*src/java/}{}' | sort | uniq -c | grep -v " 1 "
>2 org/apache/lucene/analysis/cn/package.html
>2 org/apache/lucene/queryParser/package.html
> hoss...@brunner:~/lucene/java$ find src contrib -path
> \*queryParser/package.html
> src/java/org/apache/lucene/queryParser/package.html
> contrib/queryparser/src/java/org/apache/lucene/queryParser/package.html
> hoss...@brunner:~/lucene/java$ find src contrib -path \*cn/package.html
> contrib/analyzers/common/src/java/org/apache/lucene/analysis/cn/package.html
> contrib/analyzers/smartcn/src/java/org/apache/lucene/analysis/cn/package.html
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
Parallel incremental indexing
Hi all, I just added a wiki page for a new feature I'd like to add to Lucene. Please take a look at the link. I will add more details and diagrams to the page, but for now it should give a rough idea about how to implement it: http://wiki.apache.org/lucene-java/ParallelIncrementalIndexing Basically the idea is to allow updating documents partially, e.g. only a subset of the fields without having to reindex the entire document. This is a feature that is very often asked for. We have implemented the solution in IBM and it's working great. It is a technology that allowed us already to add really exciting new features to products that weren't easily possible before. The implementation I can currently contribute has some limitations: e.g. multi-threaded indexing is not supported. But let me make clear that this is not a limitation of the design described in the wiki - we have these limitations because we implemented this on top of Lucene's 2.4 APIs. If we decide to add this to Lucene's core we should reimplement some parts to overcome those limitations. In my opinion this will be a great addition to Lucene that many people will find very useful. In Solr this is also something users often ask for. In the last weeks I worked on getting internal approval for the contribution to Lucene and the good news is that I already have a signed software grant ready - so if the community likes this feature and decides to add this to Lucene there won't be any delay for legal work from IBM's side. Btw: I will be on vacation from 09/03-09/20 and won't have internet access most of the time, so if I stop responding end of next week you'll know why... Please let me know what you think! Michael - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
