On Thu, Feb 12, 2015 at 8:43 AM, Robert Muir <rcm...@gmail.com> wrote:
> Honestly i dont agree. I don't know what you are trying to do, but if > you want file format backwards compat working, then you need a > different FilterCodec to match each lucene codec. > > Otherwise your codec is broken from a back compat standpoint. Wrapping > the latest is an antipattern here. > I understand this logic. It leaves me wandering between: 1: My old desire to convince you that there should be a way to do DirectPostingFormat's caching without being a codec at all. Unfortunately, I got dragged away from the benchmarking that might have been persuasive. 2: The problem of deprecation. I give someone a jar-of-code that works fine with Lucene 4.9. It does not work with 4.10. Now, maybe the answer here is that the codec deprecation is fundamental to the definition of moving from 4.9 to 4.10, so having a codec means that I'm really married to a process of making releases that mirror Lucene releases. > > > On Thu, Feb 12, 2015 at 5:33 AM, Benson Margulies <ben...@basistech.com> > wrote: > > Based on reading the same comments you read, I'm pretty doubtful that > > Codec.getDefault() is going to work. It seems to me that this > > situation renders the FilterCodec a bit hard to to use, at least given > > the 'every release deprecates a codec' sort of pattern. > > > > > > > > On Thu, Feb 12, 2015 at 3:20 AM, Uwe Schindler <u...@thetaphi.de> wrote: > >> Hi, > >> > >> How about Codec.getDefault()? It does indeed not necessarily return the > newest one (if somebody changes the default using Codec.setDefault()), but > for your use case "wrapping the current default one", it should be fine? > >> > >> I have not tried this yet, but there might be a chicken-egg problem: > >> - Your codec will have a separate name and be listed in META-INF as > service (I assume this). So it gets discovered by the Codec discovery > process and is instantiated by that. > >> - On loading the Codec framework the call to codec.getDefault() might > get in at a time where the codecs are not yet fully initialized (because it > will instantiate your codec while loading the META-INF). This happens > before the Codec class is itself fully statically initialized, so the > default codec might be null... > >> So relying on Codec.getDefault() in constructors of filter codecs may > not work as expected! > >> > >> Maybe try it out, was just an idea :-) > >> > >> Uwe > >> > >> ----- > >> Uwe Schindler > >> H.-H.-Meier-Allee 63, D-28213 Bremen > >> http://www.thetaphi.de > >> eMail: u...@thetaphi.de > >> > >> > >>> -----Original Message----- > >>> From: Benson Margulies [mailto:bimargul...@gmail.com] > >>> Sent: Thursday, February 12, 2015 2:11 AM > >>> To: java-user@lucene.apache.org > >>> Subject: A codec moment or pickle > >>> > >>> I have a class that extends FilterCodec. Written against Lucene 4.9, > it uses the > >>> Lucene49Codec. > >>> > >>> Dropped into a copy of Solr with Lucene 4.10, it discovers that this > codec is > >>> read-only in 4.10. Is there some way to code one of these to get 'the > default > >>> codec' and not have to chase versions? > >>> > >>> --------------------------------------------------------------------- > >>> 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 > >
