[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791933#action_12791933
]
Yonik Seeley commented on SOLR-1664:
------------------------------------
SchemaField is final and very light weight for a reason - dynamic field
creation. All polymorphic behavior goes through the FieldType.
It's also the case that it can be safely published to other threads (so we
could easily have a cache of dynamic fields if it ever turned out to be a
significant cost).
Changing this design for the same of avoiding two string catenations during the
creation of a query really doesn't seem to make sense or meet the bar.
It also doesn't seem to make much sense to split polymorphic behavior between
FieldType and SchemaField. Existing code that used FieldType methods could be
getting the wrong implementation. What *could* make sense is having a
SchemaFieldFactory and a SchemaField, with all of the polymorphic behavior
encapsulated in SchemaField. The factory would just be responsible for
argument parsing and SchemaField creation (like our TokenFilterFactory today).
That's a relatively significant change though... not something we could
contemplate for 1.5?
> Some Methods in FieldType actually should be in SchemaField
> -----------------------------------------------------------
>
> Key: SOLR-1664
> URL: https://issues.apache.org/jira/browse/SOLR-1664
> Project: Solr
> Issue Type: Improvement
> Reporter: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1664.patch
>
>
> The following methods are only overridable from FieldType.
> {code:java}
> public Field createField(SchemaField field, String externalVal, float boost) ;
> protected Field.TermVector getFieldTermVec(SchemaField field,String
> internalVal) ;
> protected Field.Store getFieldStore(SchemaField field,String internalVal);
> protected Field.Index getFieldIndex(SchemaField field,String internalVal);
> public ValueSource getValueSource(SchemaField field, QParser parser);
> public Query getRangeQuery(QParser parser, SchemaField field, String part1,
> String part2, boolean minInclusive, boolean maxInclusive) ;
> {code}
> if there is anything specific to be done on a per-field basis it is not
> possible. if we allow overriding SchemaField it will be more flexible.
> I hope this can make it simpler to implement SOLR-1131
> So ,there are two ways of overriding a functionality.
> * Override Fieldtype#createSchemaField() and provide new implementation of
> SchemaField
> * Override methods from FieldType itself(if the behavior is not per field )
> as it is now
> SchemaField is made non-final and Solr only invokes methods on SchemaField
> and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
