This probably warrants a CHANGES entry?
-Yonik
http://www.lucidimagination.com
On Fri, Oct 23, 2009 at 1:07 PM, wrote:
> Author: markrmiller
> Date: Fri Oct 23 17:07:22 2009
> New Revision: 829128
>
> URL: http://svn.apache.org/viewvc?rev=829128&view=rev
> Log:
> LUCENE-2003: Highlighter does
On Fri, Oct 23, 2009 at 6:00 PM, Uwe Schindler wrote:
> I try to get the rest of search deprecations away in 3.0, but then we should
> be sure, that there are no more such problems like with the posIncrement in
> QueryParser that need additional changes in 2.9.1 API.
That sounds like a big job th
On Mon, Oct 26, 2009 at 12:43 PM, Uwe Schindler wrote:
> Looks good. One thing:
>
> In Mark's artifacts, he changed the common-build.xml to not have -dev in the
> version before the release. You can see this in SVN. I am fine with having
> -dev in the source artefact, because if someone compiles h
On Wed, Oct 28, 2009 at 7:53 AM, Michael McCandless
wrote:
> As a followon to LUCENE-1573, we had stated that in 3.0 instead of
> throwing RuntimeException when a Thread inside Lucene is interrupted,
> we would throw InterruptedException.
>
> Do we want to do this? Technically I think it's the ri
On Thu, Oct 29, 2009 at 7:27 PM, Michael McCandless
wrote:
> OK, let's try this again!
>
> I've built new release artifacts from svn rev 831145 (on the 2.9
> branch), here:
>
> http://people.apache.org/~mikemccand/staging-area/rc3_lucene2.9.1/
>
> Changes are here:
>
> http://people.apache.org/~
+1
-Yonik
On Tue, Nov 3, 2009 at 5:05 AM, Michael McCandless
wrote:
> OK, again!
>
> I've built new release artifacts from svn rev 832363 (on the 2.9
> branch), here:
>
> http://people.apache.org/~mikemccand/staging-area/rc4_lucene2.9.1/
>
> Changes are here:
>
> http://people.apache.org/~mike
What should the next version of Solr be?
Options:
- have a Solr 1.5 with a lucene 2.9.x
- have a Solr 1.5 with a lucene 3.x, with weaker back compat given all
of the removed lucene deprecations from 2.9->3.0
- have a Solr 2.0 with a lucene 3.x
-Yonik
http://www.lucidimagination.com
-
Oops... of course I meant to post this in solr-dev.
-Yonik
http://www.lucidimagination.com
On Wed, Nov 18, 2009 at 8:53 PM, Yonik Seeley
wrote:
> What should the next version of Solr be?
>
> Options:
> - have a Solr 1.5 with a lucene 2.9.x
> - have a Solr 1.5 with a lucene 3.x, w
Thanks Bogdan, I've been meaning to bring this up.
Solr used a TreeMap in the past (when it handled it's own deletes) for
the same exact reason. In my profiling, I've also seen applyDeletes()
taking the bulk of the time with small/simple document indexing.
So we should definitely go in sorted ord
On Tue, Dec 8, 2009 at 10:25 AM, Michael McCandless
wrote:
> Sorry, right, test passed on trunk, but it's still not valid even on
> trunk (I think?). Ie TermEnum.term() is undefined until you've called
> next?
You're thinking TermDocs I think - TermEnum.term() is defined to be
positioned on or a
On Tue, Jan 12, 2010 at 6:27 PM, Marvin Humphrey wrote:
> return (targetSize >> 3) + (targetSize < 9 ? 3 : 6) + targetSize;
>
> For input values of 9 or greater, all that formula does is multiply by 1.125
> and add 6. (Values enumerated below my sig.)
>
> The comment appears to have originated
On Wed, Jan 20, 2010 at 11:21 AM, Dawid Weiss wrote:
> Is there anyone with access to an Intel I7-machine? I'd be curious
> what the results of this benchmark are, given the new JVM intrinsics
> introduced in HotSpot 1.7:
FYI, the AMD Phenom also has the POPCNT instruction.
-Yonik
http://www.luc
On Thu, Jan 28, 2010 at 8:24 AM, Michael McCandless
wrote:
> Bummer.
>
> So the only viable workarounds are 1) don't use Thread.interrupt (nor,
> things like Future.cancel, which in turn use Thread.interrupt) with
> NIOFSDir, or 2) we fix NIOFSDir to reopen the channel AND the app must
> make a de
On Thu, Jan 28, 2010 at 3:49 PM, Grant Ingersoll wrote:
> Could we get the Channel (and other necessary classes) implementation from
> Apache Harmony
Public JDK methods don't have the low level stuff to implement our
own, so rolling our own or using Harmony would require native code...
not a goo
On Thu, Feb 11, 2010 at 9:54 AM, Shay Banon wrote:
> I would like to try and improve concurrency in Lucene in several places,
> and thought I would start with FieldCacheImpl. The implementation is heavily
> synchronized on both a global map and on creation values for a pretty
> heavily used pat
On Fri, Feb 12, 2010 at 1:50 AM, Shay Banon wrote:
> On Thu, Feb 11, 2010 at 5:41 PM, Yonik Seeley
>> It really shouldn't be heavily used.
>> For a sorted search, get() is called once per segment in the index.
>> There is no synchronization to retrieve per-document valu
On Fri, Feb 26, 2010 at 3:31 PM, Jason Rutherglen
wrote:
>> I've never tried to learn a command-line invocation of a test
>> case for a single test method, I've always just used the IDE
>> to run individual methods
>
> Right, I've been doing bunches of Solr dev which for me only works
> from t
I've merged JIRA permissions - let me know if I accidentally left anyone out.
Looking forward to the communities working more closely again!
(go Robert, go! ;-)
-Yonik
On Sun, Mar 14, 2010 at 10:44 AM, Grant Ingersoll wrote:
> Per the vote on general@ to merge committers, I've given Lucene and
On Sun, Mar 14, 2010 at 5:47 PM, Mark Miller wrote:
> On 03/14/2010 06:37 PM, Grant Ingersoll wrote:
>>
>> On Mar 14, 2010, at 2:03 PM, Uwe Schindler wrote:
>>
>>
>>>
>>> This time a +1 without discuss :-)
>>>
>>
>> Yeah, but Uwe, the thread was DISCUSS, not VOTE! :-)
>>
>
> I had a whole spiel a
Due to a tremendous amount of work by our newly merged committer
corps, the get-on-lucene-trunk branch (branches/solr) is ready for
prime-time as the new solr trunk! Lucene and Solr need to move to a
common trunk for a host of reasons, including single patches that can
cover both, shared tags and
On Tue, Mar 16, 2010 at 2:51 AM, Michael Busch wrote:
> Also, we're in review-and-commit process, not commit-and-review. Changes
> have to be
> proposed, discussed and ideally attached to jira as patches first.
Correction, just for the sake of avoiding future confusion (i.e. I'm
not making any
On Tue, Mar 16, 2010 at 5:42 AM, Michael McCandless
wrote:
> I think it like the 1st option best (lucene moves as subdir to solr's
> current trunk SVN path), but I don't feel strongly.
>
> This'd mean one could simply checkout lucene alone and do everything
> you can do today.
>
> But if you check
IRC has been discussed to death at Apache:
http://markmail.org/search/?q=IRC+list%3Aorg.apache.incubator.general
Look for the spikes... like this:
http://markmail.org/search/?q=IRC+list%3Aorg.apache.incubator.general#query:IRC%20list%3Aorg.apache.incubator.general%20date%3A200608%20+page:1+state:
On Tue, Mar 16, 2010 at 5:42 PM, Jake Mannix wrote:
> On Tue, Mar 16, 2010 at 2:31 PM, Michael McCandless
> wrote:
>>
>> If we move lucene under Solr's existing svn path, ie:
>>
>> /solr/trunk/lucene
>
> Chiming in just a bit here - isn't there any concern that independent of
> whether or not pe
On Tue, Mar 16, 2010 at 6:01 PM, Jake Mannix wrote:
> I'm not concerned with casual downloaders. I'm talking about the companies
> and people who
> may or may not be interested in making multi-million dollar decisions
> regarding using or
> not using Lucene or Solr.
Heh - multi-million dollar de
E, let's strive for slightly better commit messages ;-)
-Yonik
On Thu, Mar 18, 2010 at 7:48 AM, wrote:
> Author: uschindler
> Date: Thu Mar 18 11:48:11 2010
> New Revision: 924731
>
> URL: http://svn.apache.org/viewvc?rev=924731&view=rev
> Log:
> LUCENE-2326: As rmuir seems to bug me about t
wait, wait... no...
solr-and-some-java-apis-...@lucene.apache.org
-Yonik
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
On Mon, Mar 22, 2010 at 2:20 PM, Ryan McKinley wrote:
> I'm confused... what is the need for a new name? The only place where
> there is a conflict is in the top level svn tree...
Agree, no need to re-brand.
> What about something general like:
> https://svn.apache.org/repos/asf/lucene/dev
> or
On Mon, Mar 22, 2010 at 2:25 PM, Shai Erera wrote:
> To the best of my knowledge, it
> hasn't been decided that Lucene and Solr merge and become ONE thing
Depends on what the meaning of "thing" is ;-)
We have merged into one development project. But Lucene and Solr as
separate downloads will re
For Solr, we can just move the current trunk to a 15 branch.
-Yonik
On Tue, Mar 23, 2010 at 9:39 AM, Grant Ingersoll wrote:
>
> On Mar 22, 2010, at 8:27 AM, Uwe Schindler wrote:
>
>> Hi all,
>>
>> the discussion where to do the development after the merge, now gets actual:
>>
>> Currently a luso
Of you have checkouts of the previous trunks that you don't want to
re-checkout, then use svn switch.
Solr trunk was moved to a 1.5 branch, so for old trunk checkouts, cd
into your directory and do
svn switch https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.5-dev
For "newtrunk" chec
On Tue, Mar 23, 2010 at 10:49 AM, Grant Ingersoll wrote:
>
> On Mar 23, 2010, at 10:09 AM, Grant Ingersoll wrote:
>
>>
>> 3. Other nightly build stuff. My cron tabs, etc. I will update them to
>> point at the new trunk.
>
> OK, I updated my cron tab for the site check out of Lucene. Not sure w
On Tue, Mar 23, 2010 at 5:07 PM, Michael Busch wrote:
> OK I reran the tests sequentially with my LUCENE-2329 patch applied. The
> same test failed again:
>
> [junit] Test org.apache.solr.client.solrj.embedded.JettyWebappTest FAILED
>
>
> Everything else looks good. So it should be ok to commit
On Wed, Mar 31, 2010 at 9:06 AM, wrote:
> JIRA-2353: Config incorrectly handles Windows absolute pathnames
The JIRA-2353 part is my fault - Shai asked me the right format for
JIRA linking, and I got it wrong!
Should be LUCENE-2353 of course. need...more...coffee...
-Yonik
On Wed, Apr 14, 2010 at 10:39 AM, DM Smith wrote:
> Maybe have the index store the version(s) and use that when constructing a
> reader or writer?
That would cause a reindex to change behavior (among other problems).
-Yonik
Apache Lucene Eurocon 2010
18-21 May 2010 | Prague
On Wed, Apr 14, 2010 at 11:06 AM, Chris Male wrote:
> While having fewer boxes means fewer term queries to make against the index,
> more documents means more costly calculations to filter out those extraneous
> documents.
Filtering out documents (greater selectivity) seems like it should be
the
On Wed, Apr 14, 2010 at 12:12 PM, Chris Male wrote:
> On Wed, Apr 14, 2010 at 6:07 PM, Grant Ingersoll
>> On Apr 14, 2010, at 11:06 AM, Chris Male wrote:
>> > For those doing just Cartesian Tier filtering it seems like the new
>> > approach is a win, but for those doing distance calculations on t
Seamless online upgrades have their place too... say you are upgrading
one server at a time in a cluster.
-Yonik
Apache Lucene Eurocon 2010
18-21 May 2010 | Prague
On Thu, Apr 15, 2010 at 8:42 AM, Earwin Burrfoot wrote:
> I like the idea of index conversion tool over silent online upgrade
> beca
On Thu, Apr 15, 2010 at 9:39 AM, Earwin Burrfoot wrote:
> On Thu, Apr 15, 2010 at 17:17, Yonik Seeley
> wrote:
>> Seamless online upgrades have their place too... say you are upgrading
>> one server at a time in a cluster.
>
> Nothing here that can't be solved w
On Wed, Apr 14, 2010 at 5:22 PM, Michael McCandless
wrote:
> * There is no back compat across major releases (index nor APIs),
> but full back compat within branches.
>
> This would match how many other projects work (KS/Lucy, as Marvin
> describes above; Apache Tomcat; Hibernate; log4J; FreeB
Reporter: Yonik Seeley
Assigned To: Yonik Seeley
A non-recursive implementation of MultiTermDocs.next() and skipTo() would be
nice as it's currently possible to get a stack overflow in very rare situations.
--
This message is automatically generated by JIRA.
-
If you think it was
[ http://issues.apache.org/jira/browse/LUCENE-729?page=all ]
Yonik Seeley updated LUCENE-729:
Attachment: MultiTermDocs.patch
Attaching non-recursive version.
Seems simple enough, but I'll wait till tomorrow to commit as I'm home sick
to
[ http://issues.apache.org/jira/browse/LUCENE-729?page=all ]
Yonik Seeley resolved LUCENE-729.
-
Resolution: Fixed
Committed.
Thanks for the review Michael, off the top of my head, I don't know of other
recursive functions like this.
> non-r
[
http://issues.apache.org/jira/browse/LUCENE-723?page=comments#action_12454065 ]
Yonik Seeley commented on LUCENE-723:
-
Committed.
> QueryParser support for MatchAllDocs
>
>
>
[ http://issues.apache.org/jira/browse/LUCENE-723?page=all ]
Yonik Seeley resolved LUCENE-723.
-
Resolution: Fixed
> QueryParser support for MatchAllDocs
>
>
> Key: LUCENE-723
>
[
http://issues.apache.org/jira/browse/LUCENE-736?page=comments#action_12454955 ]
Yonik Seeley commented on LUCENE-736:
-
Great investigations Doron!
Personally I'm more concerned with (1) than (2). Was the fix for one issue
[
http://issues.apache.org/jira/browse/LUCENE-738?page=comments#action_12455495 ]
Yonik Seeley commented on LUCENE-738:
-
Sounds like a good idea!
> read/write .del as d-gaps when the deleted bit vector is sufficiently spa
[
http://issues.apache.org/jira/browse/LUCENE-738?page=comments#action_12456221 ]
Yonik Seeley commented on LUCENE-738:
-
Doron, I agree with what you have described so far.
One question... are d-gaps written as a 4 byte integer or as a
[
http://issues.apache.org/jira/browse/LUCENE-738?page=comments#action_12456239 ]
Yonik Seeley commented on LUCENE-738:
-
Did a quick code review, everything looks good to me.
+1
> read/write .del as d-gaps when the deleted bit vector
[
http://issues.apache.org/jira/browse/LUCENE-682?page=comments#action_12456258 ]
Yonik Seeley commented on LUCENE-682:
-
Frankly, I'm not excited about a 6% performance loss so that someone can
customize
a total of 3 tokens that don&
[
http://issues.apache.org/jira/browse/LUCENE-682?page=comments#action_12456294 ]
Yonik Seeley commented on LUCENE-682:
-
Something like this perhaps:
public static String change(String s, String AND, String OR, String NOT) {
int len
[
http://issues.apache.org/jira/browse/LUCENE-682?page=comments#action_12456295 ]
Yonik Seeley commented on LUCENE-682:
-
That's untested code of course... I just noticed that
case '\\' : b.append(s.charAt(++i)); bre
[
http://issues.apache.org/jira/browse/LUCENE-739?page=comments#action_12456505 ]
Yonik Seeley commented on LUCENE-739:
-
+1, looks great Michael!
> Performance improvement for SegmentMerger.mergeNo
[
http://issues.apache.org/jira/browse/LUCENE-740?page=comments#action_12457458 ]
Yonik Seeley commented on LUCENE-740:
-
Speaking of licensing, that should probably be cleaned up.
> Bugs in contrib/snowball/.../SnowballProgram.j
Reporter: Yonik Seeley
Priority: Minor
Just attempting to inspect a BooleanQuery allocates two new arrays. This could
be cheaper.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http
[ http://issues.apache.org/jira/browse/LUCENE-745?page=all ]
Yonik Seeley updated LUCENE-745:
Attachment: BooleanQuery.patch
Changes:
- Vector changed to ArrayList for efficiency to remove unneeded synchronization
- added clauses() method to return
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12457582 ]
Yonik Seeley commented on LUCENE-565:
-
Lack of committer time... I've been busy enough that I've shied away from
complexity and gravitated toward i
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12457758 ]
Yonik Seeley commented on LUCENE-565:
-
> It would be nice to not have to continually open and close readers on segments
> that aren't involved in
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12457789 ]
Yonik Seeley commented on LUCENE-565:
-
> Good idea! I think this could also be used by reopen (LUCENE-743 ) to re-use
> readers.
Yes, although
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12457833 ]
Yonik Seeley commented on LUCENE-565:
-
On 12/12/06, Ning Li <[EMAIL PROTECTED]> wrote:
> > To minimize the number of reader open/closes on larg
[ http://issues.apache.org/jira/browse/LUCENE-742?page=all ]
Yonik Seeley resolved LUCENE-742.
-
Resolution: Fixed
Thanks Paul,
committed.
> SpanOrQuery.java: simplification and test
> -
>
>
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12457885 ]
Yonik Seeley commented on LUCENE-565:
-
Hmmm, I see your point... If deletes are deferred, a different reader could go
and open the index and see the additions
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12458170 ]
Yonik Seeley commented on LUCENE-565:
-
> both inserts and deletes - are committed in the same transaction.
OK, cool. I agree that's the ideal
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12458174 ]
Yonik Seeley commented on LUCENE-565:
-
Minor question... in the places that you use Vector, is there a reason you
aren't using ArrayList?
And in methods
earch
Affects Versions: 2.0.1
Reporter: Yonik Seeley
Assigned To: Yonik Seeley
finalizers are expensive, and we should avoid using them where possible.
It looks like this helped to tickle some kind of bug (looks like a JVM bug?)
http://www.nabble.com/15-minute-ha
[ http://issues.apache.org/jira/browse/LUCENE-750?page=all ]
Yonik Seeley updated LUCENE-750:
Attachment: IndexInput_finalizer.patch
Changes:
- moved finalizer to the resource that actually needs it... the Descriptor
(subclass of RandomAccessFile
[
http://issues.apache.org/jira/browse/LUCENE-749?page=comments#action_12458838 ]
Yonik Seeley commented on LUCENE-749:
-
Thanks Antonio,
Could you attach a patch (and click "Grant license to ASF for inclusion in ASF
works")
If
[ http://issues.apache.org/jira/browse/LUCENE-750?page=all ]
Yonik Seeley updated LUCENE-750:
Attachment: IndexInput_finalizer.patch
Forgot to remove the finalizer from FSIndexInput in the first patch.
Note that I also removed the finalizer from
Feature
Components: Store
Reporter: Yonik Seeley
As suggested by Doug, we could use NIO pread to avoid synchronization on the
underlying file.
This could mitigate any MT performance drop caused by reducing the number of
files in the index format.
--
This message is
[ http://issues.apache.org/jira/browse/LUCENE-753?page=all ]
Yonik Seeley updated LUCENE-753:
Attachment: FSIndexInput.patch
Patch for FSIndexInput to use a positional read call that doesn't use explicit
synchronization. Note that the implement
[
http://issues.apache.org/jira/browse/LUCENE-753?page=comments#action_12459724 ]
Yonik Seeley commented on LUCENE-753:
-
This change should be faster on heavily loaded multi-threaded servers using the
non-compound index format.
Performance
/jira/browse/LUCENE-754
Project: Lucene - Java
Issue Type: Bug
Reporter: Yonik Seeley
Assigned To: Yonik Seeley
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
[ http://issues.apache.org/jira/browse/LUCENE-754?page=all ]
Yonik Seeley updated LUCENE-754:
Attachment: FieldCache.patch
typo in original (used reader instead of key)
> FieldCache keeps hard references to readers, doesn't prevent multiple
[ http://issues.apache.org/jira/browse/LUCENE-750?page=all ]
Yonik Seeley resolved LUCENE-750.
-
Resolution: Fixed
committed.
> don't use finalizers for FSIndexInput clones
>
>
>
[
http://issues.apache.org/jira/browse/LUCENE-753?page=comments#action_12459805 ]
Yonik Seeley commented on LUCENE-753:
-
CSIndexInput synchronization could also be elimitated if there was a pread
added to IndexInput
public abstract void
[
http://issues.apache.org/jira/browse/LUCENE-436?page=comments#action_12459813 ]
Yonik Seeley commented on LUCENE-436:
-
The more finalizers we can get rid of, the better. They are too hard to use
correctly and cause performance problems
[ http://issues.apache.org/jira/browse/LUCENE-754?page=all ]
Yonik Seeley resolved LUCENE-754.
-
Resolution: Fixed
patch committed.
> FieldCache keeps hard references to readers, doesn't prevent multiple threads
> from creating sa
[ http://issues.apache.org/jira/browse/LUCENE-753?page=all ]
Yonik Seeley updated LUCENE-753:
Attachment: FSIndexInput.patch
Here is a patch that directly extends IndexInput to make things a little easier.
I started with the code for BufferedIndexInput
[
http://issues.apache.org/jira/browse/LUCENE-753?page=comments#action_12459967 ]
Yonik Seeley commented on LUCENE-753:
-
Thanks for the pointer Bogdan, it's interesting you use transferTo instead of
read... is there any advantage to
[
http://issues.apache.org/jira/browse/LUCENE-756?page=comments#action_12460285 ]
Yonik Seeley commented on LUCENE-756:
-
Seems like a good idea... given that norms are read once on-demand, I wouldn't
expect anything search related
[
http://issues.apache.org/jira/browse/LUCENE-756?page=comments#action_12460287 ]
Yonik Seeley commented on LUCENE-756:
-
> - CFS now also maintains all norms in a single file.
Does this mean a separate file outside the final .cfs fi
[
http://issues.apache.org/jira/browse/LUCENE-753?page=comments#action_12460289 ]
Yonik Seeley commented on LUCENE-753:
-
> The Javadoc says that transferTo can be more efficient because the OS can
> transfer bytes
> directly
[ http://issues.apache.org/jira/browse/LUCENE-753?page=all ]
Yonik Seeley updated LUCENE-753:
Attachment: FileReadTest.java
Attaching test that reads a file in different ways, either random access or
serially, from a number of threads.
> Use
[
http://issues.apache.org/jira/browse/LUCENE-753?page=comments#action_12460363 ]
Yonik Seeley commented on LUCENE-753:
-
Single-threaded random access performance of a fully cached 64MB file on my
home PC (WinXP) , Java6:
config: impl
[
https://issues.apache.org/jira/browse/LUCENE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462138
]
Yonik Seeley commented on LUCENE-510:
-
I'd like to see everything kept as bytes for as long as possible (
[
https://issues.apache.org/jira/browse/LUCENE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved LUCENE-756.
-
Resolution: Fixed
Committed. Thanks Doron!
> Maintain norms in a single file .
[
https://issues.apache.org/jira/browse/LUCENE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462914
]
Yonik Seeley commented on LUCENE-756:
-
Hmmm, I actually did an "svn status" to see if there was anyth
[
https://issues.apache.org/jira/browse/LUCENE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463761
]
Yonik Seeley commented on LUCENE-769:
-
Those performance numbers don't make sense to me.
Why would DocCa
[
https://issues.apache.org/jira/browse/LUCENE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463787
]
Yonik Seeley commented on LUCENE-769:
-
Sorry for some of the redundant comments... Chucks comment wasn't vi
[
https://issues.apache.org/jira/browse/LUCENE-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464350
]
Yonik Seeley commented on LUCENE-771:
-
Sounds good, I agree with all the changes you outlined.
> Change defa
[
https://issues.apache.org/jira/browse/LUCENE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465208
]
Yonik Seeley commented on LUCENE-756:
-
I agree that reducing the IO operations on an index open is a good thing
[
https://issues.apache.org/jira/browse/LUCENE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465216
]
Yonik Seeley commented on LUCENE-756:
-
As an aside, I think we need to start making more frequent releases
[
https://issues.apache.org/jira/browse/LUCENE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved LUCENE-745.
-
Resolution: Fixed
Closing... this patch has already been committed.
> Make inspection
[
https://issues.apache.org/jira/browse/LUCENE-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468371
]
Yonik Seeley commented on LUCENE-565:
-
I just reviewed this, and it looks good to me.
I like how you managed to
[
https://issues.apache.org/jira/browse/LUCENE-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472499
]
Yonik Seeley commented on LUCENE-565:
-
OK I moved NewIndexModifier's methods into IndexWriter and did some
[
https://issues.apache.org/jira/browse/LUCENE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476506
]
Yonik Seeley commented on LUCENE-819:
-
I'm not sure it's a good idea adding extra checks for things t
[
https://issues.apache.org/jira/browse/LUCENE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476671
]
Yonik Seeley commented on LUCENE-819:
-
I really don't see a need to change any code. People aren
[
https://issues.apache.org/jira/browse/LUCENE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved LUCENE-819.
-
Resolution: Won't Fix
clarified Term javadoc that Terms with nulls generally result in unde
[
https://issues.apache.org/jira/browse/LUCENE-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477412
]
Yonik Seeley commented on LUCENE-818:
-
I think that accessing a closed reader should continue to be undefined
[
https://issues.apache.org/jira/browse/LUCENE-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477457
]
Yonik Seeley commented on LUCENE-818:
-
> Then, the error is something strange (eg confus
701 - 800 of 1775 matches
Mail list logo
