2011/5/12 Michael McCandless luc...@mikemccandless.com
2011/5/9 Nikola Tanković nikola.tanko...@gmail.com:
Introduction of an FieldType class that will hold all the extra
properties
now stored inside Field instance other than field value itself.
Seems like this is an easy first baby step -- leave current Field
class, but break out the type details into a separate class that can
be shared across Field instances.
Yes, I agree, this could be a good first step. Mike submitted a patch on
issue #2308. I think it's a solid base for this.
Make that Chris.
Ouch, sorry!
New FieldTypeAttribute interface will be added to handle extension
with
new
field properties inspired by IndexWriterConfig.
How would this work? What's an example compelling usage? An app
could use this for extensibility, and then make a matching codec that
picks up this attr? EG, say, maybe for marking that a field is a
primary key field and then codec could optimize accordingly...?
Well that could be very interesting scenario. It didn't rang a bell to me
for possible codec usage, but it seems very reasonable. Attributes
otherwise
don't make much sense, unless propertly used in custom codecs.
How will we ensure attribute and codec compatibility?
I'm just thinking we should have concrete reasons in mind for cutting
over to attributes here... I'd rather see a fixed, well thought out
concrete FieldType hierarchy first...
Yes, I couldn't agree more, and I also think Chris has some great ideas on
this field, given his work on Spatial indexing which tends to have use of
this additional attributes.
Refactoring and dividing of settings for term frequency and
positioning
can
also be done (LUCENE-2048)
Ahh great! So we can omit-positions-but-not-TF.
Discuss possible effects of completion of LUCENE-2310 on this project
This one is badly needed... but we should keep your project focused.
We'll tackle this one afterwards.
Good.
Adequate Factory class for easier configuration of new Field instances
together with manually added new FieldTypeAttributes
FieldType, once instantiated is read-only. Only fields value can be
changed.
OK.
Simple hierarchy of Field classes with core properties logically
predefaulted. E.g.:
NumberField,
Can't this just be our existing NumericField?
Yes, this is classic NumericField with changes proposed in LUCENE-2310.
Tim
Smith mentioned that Fieldable class should be kept for custom
implementations to reduce number of setters (for defaults).
Chris Male suggested new CoreFieldTypeAttribute interface, so maybe it
should be implemented instead of Fieldable for custom implementations, so
both Fieldable and AbstractField are not needed anymore.
In my opinion Field shoud become abstract extended with others.
Another proposal: how about keeping only Field (with no hierarchy) and
move
hierarchy to FieldType, such as NumericFieldType, StringFieldType since
this
hierarchy concerns type information only?
I think hierarchy of both types and the value containers that hold
the corresponding values could make sense?
Hmm, I think we should get more opinions on this one also.
e.g. Usage:
FieldType number = new NumericFieldType();
Field price = new Field();
price.setType(number);
// but this is much cleaner...
Field price = new NumericField();
so maybe whe should have paraller XYZField with XYZFieldType...
Am I complicating?
StringField,
This would be like NOT_ANALYZED?
Yes, strings are often one word only. Or maybe we can name it NameField,
NonAnalyzedField or something.
StringField sounds good actually...
TextField,
This would be ANALYZED?
Yes.
OK.
What is the best way to break this into small baby steps?
Hopefully this becomes clearer as we iterate.
Well, we know the first step: moving type details into FieldType class.
Yes!
Somehow tying into this as well is a stronger decoupling of the
indexer from analysis/document. Ie, what indexer needs of a document
is very minimal -- just an iterable over indexed stored values.
Separately we can still provide a full featured Document class w/
add, get, remove, etc., but that's outside of the indexer.
I'll get back to this one after additional research. Maybe we should do
couple of more interactions, then I'll summarize the conclusions.
Mike
http://blog.mikemccandless.com
Nikola
