On Thu, Dec 3, 2009 at 5:30 AM, Uwe Schindler <u...@thetaphi.de> wrote:
>> Actually TermEnum (the current API) already behaves like a normal >> iterator, right? It's only FilteredTermEnum (and, FilteredTermsEnum) >> that pre-next's itself on construction. So we should fix >> FilteredTermsEnum to not pre-next, and to remove its empty() method? > > Not really, if you get the unitialized TermEnum from IR.terms(), it is like > an iterator, but if you get it with IR.terms(Term), it is already placed on > the first term. Oh I see. > You have to then check, if it the current term is null (e.g. > exhausted if you take the last term). You see this type of code everywhere > in lucene, like in MTQ. In my opinion, it would be better here to always > call next() first (and this was often done by users, then missing the first > term). Well, terms(Term t) matches "termsEnum.seek(t)" in the flex API, which also (depending on the SeekStatus) puts you on the term, if it was present. > The new API does not have this problem, as you only get an terms > iterator for a specific field that is per default always uninitialized and > you have to call seek. But with trunk, that is not the case. Right, but upon seek'ing, you must handle the SEEK_FOUND case like you would today with terms(Term t). >> Uwe do you want to take a stab at it? Or, I can... let me know. > > I think, you know the code better, but I could find out what to do. I was thinking... the more people comfortable w/ the flex branch, before we land, the better. It's an immense change, so if more committers have a deeper knowledge of it (nudge nudge), that'd ease the transition. But if you don't want to tackle it now, that's fine, I can take it... > I would like to have an IllegalStateException if you call docFreq() or > term(), too. I think this would help people migrating from old to new code > (and rewriting their do-while code to while(next)). Hmm, we'd need to do this for all TermsEnum methods? (eg ord, docs as well). This is making me a bit nervous -- these methods are called quite a bit -- I'd rather not pick up the small perf hit for legitimate usage of the API. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
