Could there be a Version value called
LUCENE_LATEST_DANGER_USE_AT_YOUR_OWN_RISK or whatever you want to make
it.
I understand the argument about backwards compatibility but I'm with
Johannes on making things easier for those who have code which doesn't
require the compatibility. Like me. I've been using lucene since the
very beginning and don't recall ever having been bitten by any back
compatibility problems (another reason for praise for the committers)
and would rather not have to start changing literals on upgrades.
Is the plan to remove LUCENE_CURRENT altogether or to leave it in,
permanently deprecated?
If the latter we could carry on using it although living with
deprecations isn't great.
Doing simple things in lucene does in general seem to be getting
harder. Off the top of my head ...
IndexSearcher s = new IndexSearcher("/my/index");
QueryParser qp = new QueryParser("", new StandardAnalyzer());
Query q = qp.parse("field: value");
Hits h = s.search(q);
for (int i = 0; i < h.length; i++) {
System.out.println(h.doc(i).get("field"));
}
used to work. It won't now of course, and I'd have to look at the
javadocs to come up with alternatives.
Keep APIs simple!
--
Ian.
On Fri, Feb 26, 2010 at 10:50 AM, Michael McCandless
<luc...@mikemccandless.com> wrote:
> That would be more natural/convenient, but it'd unfortunately defeat
> the whole reason Version was added in the first place.
>
> By making Version required, we force callers to be explicit to Lucene
> about what level of back compat is required.
>
> This then enables Lucene to improve its defaults with each release,
> without breaking users that need to keep backwards compatibility.
>
> Mike
>
> On Fri, Feb 26, 2010 at 5:42 AM, Johannes Zillmann
> <jzillm...@googlemail.com> wrote:
>> Just one thought...
>>
>> For me it would be natural to be never confronted with the Version.xx thing
>> in the api unless you really need.
>> so f.e. having
>> new QueryParser("", new KeywordAnalyzer()).parse("content: the");
>> as a default (probably using Version.LUCENE_CURRENT under the hood), but
>> having
>> new QueryParser(Version.XXX,"", new
>> KeywordAnalyzer()).parse("content: the");
>> as well.
>>
>> Of cause this would require a lot of method/constructor overloading, but
>> would make the api more user friendly for those who write some code where
>> the version don't matter...
>> Johannes
>>
>> On Feb 26, 2010, at 11:27 AM, Paul Taylor wrote:
>>
>>> Robert Muir wrote:
>>>> such projects can do this, in one place:
>>>>
>>>> public static final Version MY_APP_CURRENT = Version.LUCENE_30;
>>>>
>>>> then later....
>>>>
>>>> StandardAnalyzer analyzer = new StandardAnalyzer(MY_APP_CURRENT);
>>>>
>>>> then they have complete control of this, independent of when the upgrade
>>>> lucene's jar file!
>>> Not quite true because you still need to update MY_APP_CURRENT when there
>>> is a new version, but yes thats more mangeable
>>>
>>> Paul
>>>
>>> ---------------------------------------------------------------------
>>> 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-user-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-user-h...@lucene.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> 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-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
