[jira] Commented: (LUCENE-497) update copyright (and licence) prior to release of 1.9

[ http://issues.apache.org/jira/browse/LUCENE-497?page=comments#action_12366438 ] Hoss Man commented on LUCENE-497: - i don't really have an opinion on the matter one way or another, I've just seen lots of files that look like this... * Copyright 2004-2005

[jira] Commented: (LUCENE-496) New tool for reseting the (length)norm of fields after changing Similarity

[ http://issues.apache.org/jira/browse/LUCENE-496?page=comments#action_12366436 ] Yonik Seeley commented on LUCENE-496: - Looks good! Should this be in the index package? You could even optionally reconstruct the boost if you wanted to (to the precisio

[jira] Commented: (LUCENE-497) update copyright (and licence) prior to release of 1.9

[ http://issues.apache.org/jira/browse/LUCENE-497?page=comments#action_12366435 ] Yonik Seeley commented on LUCENE-497: - IANAL, but I don't think the copyright dates should be changed unless a significant amount of the file has changed. The date in the

[jira] Created: (LUCENE-497) update copyright (and licence) prior to release of 1.9

update copyright (and licence) prior to release of 1.9 -- Key: LUCENE-497 URL: http://issues.apache.org/jira/browse/LUCENE-497 Project: Lucene - Java Type: New Feature Reporter: Hoss Man Priority: Minor As

Re: updating fieldNorms in mass

: > in the case where doc boosts and field boosts aren't used, it seems like : > it would be very easy to write a maintenance app that did something : > like... : > ...does anyone see anything wrong with the overall appraoch? : : Looks good to me. Implimented and submitted in LUCENE-496. So far

[jira] Updated: (LUCENE-496) New tool for reseting the (length)norm of fields after changing Similarity

[ http://issues.apache.org/jira/browse/LUCENE-496?page=all ] Hoss Man updated LUCENE-496: Attachment: LengthNormModifier.java TestLengthNormModifier.java Class with utility function, and main that calls it on an FSDirectory. Also test cases

[jira] Created: (LUCENE-496) New tool for reseting the (length)norm of fields after changing Similarity

New tool for reseting the (length)norm of fields after changing Similarity --- Key: LUCENE-496 URL: http://issues.apache.org/jira/browse/LUCENE-496 Project: Lucene - Java Type: New Feature Com

Re: 1.9 RC1

Chris Hostetter wrote: I'm not sure what the ASF/Lucene policy is on keeping Copyright/License statements in source files up to date, but should they all be updated to say "Copyright 2006 The Apache Software Foundation" prior to a 1.9 release? It shouldn't hurt! This week is pretty booked for

Re: 1.9 RC1

: I'd like to push out a 1.9 release candidate in the next week or so. I'm not sure what the ASF/Lucene policy is on keeping Copyright/License statements in source files up to date, but should they all be updated to say "Copyright 2006 The Apache Software Foundation" prior to a 1.9 release? I've

Re: Field constructor, avoiding String.intern()

I noticed that, too, but in my case the difference was often much more extreme: it was one of the primary bottlenecks on indexing. This is the primary reason why MemoryIndex.addField(...) navigates around the problem by taking a parameter of type "String fieldName" instead of type "Field":

Re: updating fieldNorms in mass

Chris Hostetter wrote: in the case where doc boosts and field boosts aren't used, it seems like it would be very easy to write a maintenance app that did something like... get instance of similarity based on input foreach fieldName in input { int[] termCounts = new int[maxDoc];

updating fieldNorms in mass

I just noticed the IndexReader.setNorm method(s) today and was extremely stoked -- after rebuilding my dev index from scratch three times last week becuase I wanted to try out tweaks to Similarity.lengthNorm the idea of being able to directly change the norms without rebuildign from scratch is loo

Field constructor, avoiding String.intern()

After profiling in-memory indexing, I noticed that calls to String.intern() showed up surprisingly high; especially the one from Field() constructor. This is understandable due to overhead String.intern() has (being native and synchronized method; overhead incurred even if String is already interne