[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761836#action_12761836
]
Uwe Schindler commented on LUCENE-1257:
---
bq. Generification of Document. It makes no
On Fri, Oct 2, 2009 at 10:18 PM, Earwin Burrfoot wrote:
> Builder pattern allows you to switch concrete implementations as you
> please, taking parameters into account or not.
We could also achieve this w/ static "factory" method. EG
IndexReader.open(IndexReader.Config) could switch between con
On Fri, Oct 2, 2009 at 10:18 PM, Earwin Burrfoot wrote:
>> Call me old fashioned, but I like how the non constructor params are set
>> now.
> And what happens when you index some docs, change these params, index
> more docs, change params, commit? Let's throw in some threads?
> You either end up w
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761839#action_12761839
]
Timo Nentwig commented on LUCENE-1257:
--
Somewhat off-topic but in the course of porti
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761841#action_12761841
]
Uwe Schindler commented on LUCENE-1257:
---
Good idea!
> Port to Java5
> -
Hi,
The problem is, we have to leave some of the not-yet-deprecated ctors/opens
available for a while (not until 4.0 with our ne policy), but a user
removing all deprecated stuff from his 2.9 release should be able to switch
to 3.0 without changing any code (can even plug the jars in). We also hav
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761843#action_12761843
]
Paul Elschot commented on LUCENE-1257:
--
For the record, there is still some usage of
Well, let's first get 3.0 out the door ;) Then we can salivate over
all sorts of juicy changes for 3.1...
These particular changes (switching syntax from multi-ctors to config
or to builder, disallowing config changes after creation, switching to
"concrete impl is hidden") may merit an exception
>> Builder pattern allows you to switch concrete implementations as you
>> please, taking parameters into account or not.
>
> We could also achieve this w/ static "factory" method. EG
> IndexReader.open(IndexReader.Config) could switch between concrete
> impls (it already does today).
Yes, the cho
Remove deprecated Directory stuff and IR/IW open/ctor hell
--
Key: LUCENE-1944
URL: https://issues.apache.org/jira/browse/LUCENE-1944
Project: Lucene - Java
Issue Type: Task
C
There's also LUCENE-1698! Maybe we can change the policy. Now that 2.9
is out we should try to get to a conclusion.
Michael
On 10/3/09 11:54 AM, Michael McCandless wrote:
Well, let's first get 3.0 out the door ;) Then we can salivate over
all sorts of juicy changes for 3.1...
These particul
[
https://issues.apache.org/jira/browse/LUCENE-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1944:
--
Attachment: LUCENE-1944.patch
A first version, some tests may use old API, which therefore not
But we should not change for 3.0, because people have already much to do to
get their 2.9 compile without deprec. If the work is then obsolete, because
we change this fundamental, we will make a lot of people angry. So I would
do this for 3.1.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Brem
Right: 3.0 should be a fast turnaround w/ no further deprecations.
(And at your rate of progress Uwe it looks like it really *will* be
fast!).
For 3.1 we can salivate...
Mike
On Sat, Oct 3, 2009 at 6:18 AM, Uwe Schindler wrote:
> But we should not change for 3.0, because people have already muc
I agree, we have announed the 2.9/3.0 release plans a long time ago
already and shouldn't change anything. But ideally I'd like to announce
any backwards-compatibility changes together with the 3.0 release, while
mentioning that the changes will take effect from 3.1 on. That's why I'd
like to g
[
https://issues.apache.org/jira/browse/LUCENE-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761850#action_12761850
]
Michael McCandless commented on LUCENE-1944:
bq. Does listAll/list difference
Now it gets slower. After applying LUCENE-1944, you get >600 errors when
compiling tests :(
We should have checked our tests in 2.9 that they only call deprecated
methods for BW compatibility. No I have to change tons of IR.open(), IW()
calls in backwards branch and also in trunk tests. But the pa
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761852#action_12761852
]
Uwe Schindler commented on LUCENE-1257:
---
I know, protected is also public from the A
On Sat, Oct 3, 2009 at 6:25 AM, Uwe Schindler wrote:
> Now it gets slower. After applying LUCENE-1944, you get >600 errors when
> compiling tests :(
>
> We should have checked our tests in 2.9 that they only call deprecated
> methods for BW compatibility.
Sigh. Yes, going forward we should proba
> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> Sent: Saturday, October 03, 2009 12:29 PM
> To: java-dev@lucene.apache.org
> Subject: Re: Lucene 2.9 and deprecated IR.open() methods
>
> On Sat, Oct 3, 2009 at 6:25 AM, Uwe Schindler wrote:
> > Now it gets slower. After applying LUC
I have a plan how to do the tests:
I use my BW branch checkout and enable deprecation warnings there. I then
start to fix all deprec usage and remove all code parts that are only there
to test bw compatibility (e.g. TestTokenStreamBWCompatibiliy). After that
the test should compile without deprec
On Oct 2, 2009, at 7:33 PM, Michael McCandless wrote:
Sigh. The introduction of new but deprecated methods is silly. Is
there some simple automated way to catch/prevent these?
The proliferation of ctors/factory methods is a nightmare.
Ah, so yet again, we are trying to work around a proble
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Elschot updated LUCENE-1257:
-
Attachment: lucene1257surround1.patch
StringBuffer to StringBuilder patch for conrib/surround
>
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761856#action_12761856
]
Paul Elschot commented on LUCENE-1257:
--
I would not expect that the protected methods
[
https://issues.apache.org/jira/browse/LUCENE-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761858#action_12761858
]
Uwe Schindler commented on LUCENE-1944:
---
Lets add a changes.txt entry in contrib abo
[
https://issues.apache.org/jira/browse/LUCENE-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1944:
--
Comment: was deleted
(was: Lets add a changes.txt entry in contrib about a BW break.)
> Remov
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761859#action_12761859
]
Uwe Schindler commented on LUCENE-1257:
---
Lets add a changes.txt entry in contrib abo
Krr, wrong issue.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Uwe Schindler (JIRA) [mailto:j...@apache.org]
> Sent: Saturday, October 03, 2009 1:26 PM
> To: java-dev@lucene.apache.org
> Subject: [jir
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1257:
--
Attachment: lucene1257surround1.patch
patch with changes.txt
> Port to Java5
> -
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761862#action_12761862
]
Karl Wettin commented on LUCENE-1257:
-
bq. Wait ... do you mean you got rid of some of
This seems to work, I have created some scripts that do the compilations and
create a deprecation report and I start to fix in BW branch. The easieist is
first to just remove a lot of tests, that only test the BW compatibility
API.
I will post something, as soon as I have removed most deprec warni
[
https://issues.apache.org/jira/browse/LUCENE-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761868#action_12761868
]
Karl Wettin commented on LUCENE-1939:
-
Patrick,
I can't manage to reproduce this erro
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761870#action_12761870
]
Karl Wettin commented on LUCENE-1257:
-
bq. Generification of Document. It makes now cl
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761872#action_12761872
]
Uwe Schindler commented on LUCENE-1257:
---
how that?
> Port to Java5
> -
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-1257:
Attachment: shinglematrixfilter_generified.patch
Generified ShingleMatrixFilter
> Port to Java5
>
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761874#action_12761874
]
Karl Wettin commented on LUCENE-1257:
-
bq. Generified ShingleMatrixFilter
Committed i
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761875#action_12761875
]
Karl Wettin commented on LUCENE-1257:
-
bq. how that?
It asserted that a Document cont
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-1257:
Attachment: instantiated_fieldable.patch
Fix for InstantiadexIndex compile error caused by code co
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761877#action_12761877
]
Karl Wettin commented on LUCENE-1257:
-
bq. Fix for InstantiadexIndex compile error cau
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761878#action_12761878
]
Uwe Schindler commented on LUCENE-1257:
---
Ah ok, the list is Fieldable. That was exac
[
https://issues.apache.org/jira/browse/LUCENE-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-1943.
-
Resolution: Fixed
Committed revision 821322.
> ChineseFilter is inefficient
> -
[
https://issues.apache.org/jira/browse/LUCENE-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir reassigned LUCENE-1916:
---
Assignee: Robert Muir
> smartcn HHMM doc translation
>
>
>
[
https://issues.apache.org/jira/browse/LUCENE-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-1916.
-
Resolution: Fixed
Committed revision 821325.
> smartcn HHMM doc translation
> -
Do not wonder, I will now commit lots of test fixes for IR.open() in
backwards branch and then merge to trunk!
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Se
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-1257:
Attachment: LUCENE-1257_messages.patch
changes o.a.l.messages (back) to varargs syntax to match th
[
https://issues.apache.org/jira/browse/LUCENE-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761907#action_12761907
]
Patrick Jungermann commented on LUCENE-1939:
Karl, your right, sorry. I used t
[
https://issues.apache.org/jira/browse/LUCENE-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761924#action_12761924
]
Karl Wettin commented on LUCENE-1939:
-
The exception is thrown when ts#next (increment
I suppose that should have been suggested before 2.9 rather than
after...
There are at least three reasons to why I want to do this:
The code is based on the behaviour or the Directory IndexWriter as of
2.3 and I have not been touching it since then. If there will be
changes in the future
[
https://issues.apache.org/jira/browse/LUCENE-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1944:
--
Attachment: LUCENE-1944.patch
Updated patch, works with current trunk and backwards branch (af
Karl,
Sure no problems, LUCENE-1313 is using a RAMDir for now.
-J
On Sat, Oct 3, 2009 at 11:00 AM, Karl Wettin wrote:
> I suppose that should have been suggested before 2.9 rather than after...
>
> There are at least three reasons to why I want to do this:
>
> The code is based on the behaviour
[
https://issues.apache.org/jira/browse/LUCENE-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761950#action_12761950
]
Patrick Jungermann commented on LUCENE-1939:
Here is the complete stacktrace:
I'm working on migrating my code to 2.9. And I'm trying to figure out
what to do. Along the way I found a circular argument in the JavaDoc
for Searcher. BTW, this is not a user question.
My current code calls:
Hits hits = searcher.search(query);
The JavaDoc for it says:
/**
Writing a Collector is the correct and fastest way to do this. The Javadoc
pointing to deprec API is incorrect.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
_
From: DM Smith [mailto:dmsmith...@gmail.com]
Sent: Sunday, October 04
You used Hits to get all that hits? Nasty man - thats we deprecated that
class - even though the JavaDoc warns you thats a major speed trap,
everyone still did it ... use a Collector.
Your right though - it shouldn't point to IndexSearcher.search(Query)
after that - it should point to IndexSearche
I think it could be reworded as well - its kind of uhh ... but I'll
leave that to someone else if they care. For now I just pointed it to
the correct method.
Mark Miller wrote:
> You used Hits to get all that hits? Nasty man - thats we deprecated that
> class - even though the JavaDoc warns you th
Should we fix these kind of things in the 2.9 branch too?
I'm 99.9% sure we'll have a 2.9.1 release - 3.0 will be a bunch of work
for users to upgrade, so we should definitely deliver a bugfix release
for 2.9, even if we (hopefully) only find minor bugs.
Michael
On 10/4/09 12:14 AM, markrmil
Why will 3.0 be work to upgrade? 2.9 was supposed to be the work, 3.0 no
work ...
In either case, I don't mind a 2.9.1 - but it hadn't been planned yet
that I saw.
Michael Busch wrote:
> Should we fix these kind of things in the 2.9 branch too?
> I'm 99.9% sure we'll have a 2.9.1 release - 3.0 wi
[
https://issues.apache.org/jira/browse/LUCENE-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1944:
--
Attachment: LUCENE-1944-contrib-fixes.patch
Here are the fixes for contrib to not use the depr
On 10/4/09 12:42 AM, Mark Miller wrote:
Why will 3.0 be work to upgrade? 2.9 was supposed to be the work, 3.0 no
work ...
With 2.9 you can be lazy and live with deprecation warnings. With 3.0
you *have* to switch to undeprecated APIs.
Michael
In either case, I don't mind a 2.9.1 - but
Should we now commit all fixes also to 2.9, which should go into 2.9.1, i
fit will be released as a bugfix release together with 3.0 (e.g. the
highlighter problem)?
If yes, I would merge some of my commits into 2.9 (not the ones from today,
hihi).
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-
No bug fixes for the lazy!
:)
We should also fix Hits then - how about something like:
* @deprecated
* see {...@link Searcher#search(Query, int)} and {...@link
Searcher#search(Query, Sort)}
* as well as the variants that take a {...@link Filter} :
*
* TopDocs topDocs = searcher.search(qu
Whoops - there is no short sort method:
* @deprecated
* see {...@link Searcher#search(Query, int)}, {...@link Searcher#search(Query,
Filter, int)}
* and {...@link Searcher#search(Query, Filter, int, Sort)}:
*
* TopDocs topDocs = searcher.search(query, numHits);
* ScoreDoc[] hits = topD
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761970#action_12761970
]
Uwe Schindler commented on LUCENE-1257:
---
Committed Revision: 821443 (Change some occ
[
https://issues.apache.org/jira/browse/LUCENE-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761971#action_12761971
]
Uwe Schindler commented on LUCENE-1944:
---
I think, I have to commit this now. The cur
[
https://issues.apache.org/jira/browse/LUCENE-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler resolved LUCENE-1944.
---
Resolution: Fixed
Committed revision: 821446
If there are any problems caused by this, let
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761975#action_12761975
]
Uwe Schindler commented on LUCENE-1257:
---
Committed revision: 821447 (o.a.l.messages
On 10/3/09 4:18 AM, Earwin Burrfoot wrote:
Builder pattern allows you to switch concrete implementations as you
please, taking parameters into account or not.
Besides that there's no real difference. I prefer builder, but that's just me :)
Why can't you do that with a factory that takes a
I think my preference is swayed by convention/simplicity. The way things
are done now are just very intuitive for me. When I sit down to write
some code with Lucene, I barley have to think or remember much. It all
sticks. Its mostly all basic Java with few patterns.
Now google has used some cool p
It makes sense if you understand the context. We make each verse of a
Bible a document. There are about 36000 docc in a Bible. We want a
user to find all the verses that match there search to give the count
of total hits. We then show slices of the hits from first hit to last
im document or
On Oct 3, 2009, at 6:51 PM, Michael Busch wrote:
On 10/4/09 12:42 AM, Mark Miller wrote:
Why will 3.0 be work to upgrade? 2.9 was supposed to be the work,
3.0 no
work ...
With 2.9 you can be lazy and live with deprecation warnings. With
3.0 you *have* to switch to undeprecated APIs.
M
Please apply all bug fixes tto 2.9.0 as som of us have it as our last
Java1.4.2 release.
On Oct 3, 2009, at 6:55 PM, "Uwe Schindler" wrote:
Should we now commit all fixes also to 2.9, which should go into
2.9.1, i
fit will be released as a bugfix release together with 3.0 (e.g. the
highl
On Oct 3, 2009, at 6:56 PM, Mark Miller wrote:
No bug fixes for the lazy!
Not having 1.5 on mac osx tiger is the issue. Dou you recommend that
2.9.0 is really not for 1.4 users. Therefore was no point in waiting
on Java1.5.
:)
Yes I see that tongue in your cheek.
We should also fix
Gotchya - that clears up my mind. I know your an advanced user, so it
threw me for a loop that you would be using Hits like a Collector. Just
have been seeing that a lot lately.
Just read to much into: So what is the appropriate documentation for
getting all "hits"?
Another option (of course) is
That certainly makes sense.
DM Smith wrote:
> Please apply all bug fixes tto 2.9.0 as som of us have it as our last
> Java1.4.2 release.
>
>
>
> On Oct 3, 2009, at 6:55 PM, "Uwe Schindler" wrote:
>
>> Should we now commit all fixes also to 2.9, which should go into
>> 2.9.1, i
>> fit will be rele
The builder pattern and the config argument to a factory both have the
advantage that you can limit changes after creating an object. Some things
are just bad to change in mid-stream. The config argument is nice in that
you can pass it around to different stake holders, but the builder can be
use
Ted Dunning wrote:
>
> The builder pattern and the config argument to a factory both have the
> advantage that you can limit changes after creating an object. Some
> things are just bad to change in mid-stream. The config argument is
> nice in that you can pass it around to different stake holder
On Oct 3, 2009, at 9:23 PM, Mark Miller wrote:
Gotchya - that clears up my mind. I know your an advanced user, so it
threw me for a loop that you would be using Hits like a Collector.
Just
have been seeing that a lot lately.
Is there enough interest to add a new search method? (Hiterator?
77 matches
Mail list logo
