lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] Commented: (SOLR-2146) Custom SchemaField object
Date Mon, 11 Oct 2010 18:39:32 GMT


Hoss Man commented on SOLR-2146:

Note: the crux of the issue isn't particularly that "SchemaField" needs to be extensible in
a java sense -- it's primarily that FieldType subclasses should be able to declare properties
that can be specified in the corresponding {{<field />}} declarations by some means.

As i mentioned on the mailing list...

> something that is intended to be customized -- while FieldType
> objects are constructed once at startup, SchemaField obejcts are
> frequently created on the fly when dealing with dynamicFields, so
> initialization complexity is kept to a minimum.
> That said -- this definitely seems like that type of usecase that we
> should try to find *some* solution for -- even if it just means having
> Solr automaticly create hidden FieldType instances for you on startup
> based on attributes specified in the<field />  that the corrisponding
> FieldType class understands.

> Custom SchemaField object
> -------------------------
>                 Key: SOLR-2146
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>          Components: Schema and Analysis
>            Reporter: Renaud Delbru
>            Priority: Minor
>             Fix For: 3.1
> There is some use cases that require to extend SchemaField objects with "attributes"
or "properties".
> For example, I would like to be able to assign a specific "term mapping file" for each
of my field. Each field name will have a "mapping file" associated that I can access at query
time using the IndexSchema object.
> The FieldType object already enables the addition of attributes. However, these attributes
are "local" to a field type, not a field definition. Multiple fields can have the same field
types, which is not suitable for our use cases. 
> One possible solution will be to create one field type per field definition, but this
is more a dirty hack: it means duplicating field types, making them more difficult to maintain.
> References to mailing list discussion:

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message