Thanks,
Colton McInroy

 * Director of Security Engineering

        
Phone
(Toll Free)     
_US_    (888)-818-1344 Press 2
_UK_    0-800-635-0551 Press 2

My Extension    101
24/7 Support    [email protected] <mailto:[email protected]>
Email   [email protected] <mailto:[email protected]>
Website         http://www.dosarrest.com

On 10/21/2013 11:41 AM, Aaron McCurry wrote:

Yes, however with the API changes that have/are being discussed in others
threads (Document vs. Record, Document Collection vs.Row, etc) I want to
change the value portion of the Column to have a Value type that will be a
union in Thrift instead of a struct.  This would allow us to have all the
basic types be defined in separate fields.  This stringValue for string
types, textValue for text types, intValue for int types, etc that way when
a table is not in strict mode it could better guess the correct type
instead of blindly choosing text.
Makes sense, for my purposes this should work well enough though. I will want strictTypes=true and define column types for the column I know about, and let automatic determination take care of the unspecified fields, although that shouldn't be very many, since I should know all field types as I define them in my interface. Kinda sucks that they cannot be changed though, I'll have to build that into my GUI and make sure to take note of that.
Ok so this code is to merely add the type to be available as a type that
can be used.  After this runs your new type will act just like "text",
"int", "date", or any other built in type.  After the type is registered in
the system, either by table or system wide you will still need to call
definecolumn to make use of the new type.

So in the example.

tableDescriptor.putToTableProperties("blur.fieldtype.customfield1",
"org.apache.blur.analysis.type.ExampleType1");

"blur.fieldtype." is the important part for the loader.  The prefix tells
the TableContext that this property is a new field type.  So it takes the
value "org.apache.blur.analysis.type.ExampleType1" for example and tries to
load the class via the Class.forName method.  If successfully and if it's a
FieldTypeDefinition it will register is in the BaseFieldManager.  Then the
type is available for use.

So "customfield1" is not even used.  It's only there to makes the property
be a unique name.

Hope this helps.
Ahh... *sings* I can see clearly now the sun is out *sings*, I was misunderstanding what you meant first, that makes a lot more sense, Thanks.

Reply via email to