[
https://issues.apache.org/jira/browse/BLUR-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13695317#comment-13695317
]
Rahul Challapalli commented on BLUR-112:
----------------------------------------
Hi Aaron,
I really liked the FieldManager approach which manages FieldTypeDefinitions. We
may end up with dealing more classes but with less clutter.
As you said the TableContext would maintain a reference to the FieldManager and
we have to pass this FieldManager to the Analyzer to instantiate it. Both the
FieldManager and BlurAnalyzer still maintain the redundant field-to-analyzer
mapping. May be its OK to do it this way. But how about the below solution
class AnalyzerFieldManager implements Analyzer, FieldManager{
}
class TableContext {
AnalyzerFieldManager analyzerFieldManager;
Analyzer getAnalyzer() {
return (Analyzer) analyzerFieldManager;
}
FieldManager getFieldManager() {
return (FieldManager) analyzerFieldManager;
}
}
The class is overloaded but we can just expose the appropriate interface
without worrying about improper usage. We would still leverage the
FieldTypeDefinition class.
Usage in TransactionRecorder class might be something like :
FieldManager fieldManager = tableContext.getFieldManager();
FieldType fieldType = fieldManager.getFieldType(fieldName);
We might similarly use the Analyzer interface while dealing with the
IndexWriter.
What are your thoughts?
- Rahul
> Allow for types to be set on blur tables
> ----------------------------------------
>
> Key: BLUR-112
> URL: https://issues.apache.org/jira/browse/BLUR-112
> Project: Apache Blur
> Issue Type: Improvement
> Affects Versions: 0.2.0, 0.3.0
> Reporter: Aaron McCurry
> Fix For: 0.3.0
>
>
> Create the ability for Blur to handle the default Lucene field types. This
> should not be tied to the table descriptor because types should be allowed to
> be added at runtime. Also 2 new fields should be added to the
> TableDescriptor:
> 1. A strict types attribute. If set to true, if a new column is added to the
> table and there is no type mapping for it. Throw an exception. Set to false
> by default.
> 2. Default type is strict is set to false. The default type should be text.
> Also, dynamic columns could be allowed if their name included the type. Such
> as:
> The column name could be "col1" with a type of "int", in the Column struct in
> thrift the name would be "col1/int" and if the type did not exist before the
> call it would be added.
> Thoughts?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
