[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792855#action_12792855
]
Yonik Seeley commented on SOLR-1664:
------------------------------------
I like the direction I think... the current split between SchemaField and
FieldType forces one to often use the following pattern:
schemaField.type().soSomething(schemaField,...)
I do think FieldType should basically become the factory for SchemaField.
FieldType methods not having to do with parsing parameters and creating
SchemaFields should be deprecated and those we want to keep (i.e. not all of
them) should be moved to SchemaField. All creation of SchemaField instances
should go through the appropriate FieldType. All code in Solr that dispatches
through FieldType should be changed to dispatch through the SchemaField
instance.
This should lead to slightly cleaner code overall. The downside is really that
it doesn't end up accomplish much at all for the end user of Solr.
> 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.
