On 6/7/06, Lee Marlow <[EMAIL PROTECTED]> wrote: > Do you mean that all fields would have to be known at index creation > time or just that once a field is defined it properties are the same > across all documents? Right now I'm indexing documents that create > new fields as needed based on user defined properties, so we don't > know all the fields initially.
Hi Lee, Dynamic fields will definitely be remaining in Ferret. But, as you said, once a field is defined its properties are set for all documents. So in your case, you would set the default properties for a field to match those that you use for your user defined field. Otherwise you could use Index#add_field(<field properties>) to add a field with whatever properties you need. This functionality is going to exist in Ferret but not necessarily in Lucy. Could you describe in more what kind of user defined properties you are indexing to help convince Marvin that dynamic fields are a good thing. Cheers, Dave > On 6/5/06, Marvin Humphrey <[EMAIL PROTECTED]> wrote: > > > > On Jun 4, 2006, at 10:46 PM, David Balmain wrote: > > > > > In my experimental version of Ferret I have a fields > > > file along with the segments file. The fields file stores all the > > > field metadata such as store, index, term-vector and field boosts. > > > That way there is no need to maintain a separate FieldInfos file per > > > segment. (This will make merging a lot more difficult but I'm still > > > thinking about that one.) > > > > Robert Kirchgessner made a similar proposal: > > > > http://xrl.us/m2qq (Link to mail-archives.apache.org) > > > > Robert addresses the merging issue in a subsequent email, and I think > > his arguments are compelling. > > > > IMO, field defs should be immutable and consistent over the entire > > index. > > > > >>> So here is a possible way example of the way I'd implement this; > > >>> > > >>> # the following might even look better in a YAML file. > > >> > > >> Ooo, nifty idea! How about a class whose sole purpose is to define > > >> fields and generate the YAML file? Or, if we're thinking future > > >> Lucene 2.1 file format, some Lucene-readable index definition file? > > > > > > Now this idea I like. Perhaps even a simple question/answer app to > > > generate the index definition file. I'd guess that Lucene will > > > probably end up going with XML rather than YAML. > > > > I think it would be a binary file, using Lucene's standard > > writeString, writeVInt, etc. methods. > > > > A question/answer app could easily be built based around a module. > > > > How does "IndexCreator" sound? Take away the ability of the > > IndexWriter module to create or redefine indexes, and encapsulate > > that functionality within one module. Using Java as our lingua > > franca... > > > > IndexCreator creator = new IndexCreator(filePath); > > FieldDefinition titleDef = new FieldDefinition("title", > > Field.Store.YES, Field.Index.TOKENIZED); > > FieldDefinition bodyDef = new FieldDefinition("body", > > Field.Store.YES, Field.Index.TOKENIZED > > Field.TermVector.YES); > > creator.addFieldDefinition(titleDef); > > creator.addFieldDefinition(bodyDef); > > creator.createIndex(); > > > > Marvin Humphrey > > Rectangular Research > > http://www.rectangular.com/ > > > > _______________________________________________ > > Ferret-talk mailing list > > [email protected] > > http://rubyforge.org/mailman/listinfo/ferret-talk > > > _______________________________________________ > Ferret-talk mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/ferret-talk > _______________________________________________ Ferret-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/ferret-talk
