On Thu, Feb 12, 2015 at 8:51 AM, Benson Margulies <ben...@basistech.com> wrote: > 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.
Honestly, benchmarking won't persuade me. I think this is a trap and I don't want more of these traps. We already have RAMDirectory(Directory other) which is this exact same trap. We don't need more duplicates of it. But this Direct, man oh man is it even worse by far, because it uses 32 and 64 bits for things that really should typically only be like 8 bits with compression, so it just hogs up RAM. There isnt a benchmark on this planet that can convince me it should get any higher status. On the contrary, I want to send it into a deep dark dungeon in siberia. --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
