[
https://issues.apache.org/jira/browse/SOLR-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593854#comment-13593854
]
Hoss Man commented on SOLR-4329:
--------------------------------
My chief concerns when thinking about this new approach for "DocumentBuilder"
is that it increases the API surface of building up these documents in kind of
a scary way. In particular the wide open nature of
DocumentBuilderAwareFieldType.addFieldsToDocument means a "rouge" or buggy
FieldType could wreck all sorts of havoc.
That said: I understand smiley's motivation here with needing a way for robust
and complex FieldTypes to have more control over the number/types of concrete
"Fields" added to a Document based on the values found in the
"SolrInputDocument", and i don't have any serious objections to the general
idea, provided we do a decent job of labeling this new interface as expert and
clearly documenting the overall lifecycle of things.
Some specific comments (ignoring back compat for a moment)...
* seems like the DocumentBuilder class should be final (already defacto final
since the constructor is private right?)
* i don't see why "boost" is being passed to addFieldsToDocument, why not make
that a state variable on the DocumentBuilder with a public accesser just like
ifield ?
* need a lot more docs on a the lifecycle of things implementing
DocumentBuilderAwareFieldType - in particular how many times
addFieldsToDocument is called on a single instance (ie: once per
SolrInputField, not once per SolrInputDocument, or once per
SolrInputField.iterator())
* also need to decide if/how any order should be enforced in how
SolrInputField's are iteratored beyond just the natural order of the docs --
with a simpler DocumentBuilder this didn't matter, but now with
DocumentBuilderAwareFieldType an impl's behavior might change based on what
other fields are already in the target document (because of *other*
DocumentBuilderAwareFieldTypes already processed, or other SolrInputField's
processed by the current DocumentBuilderAwareFieldType) ... we need to ensure
that there is consistent behavior regardless of what order the client happens
to send different SolrInputFields
* we would definitely need a Mock impl of DocumentBuilderAwareFieldType to test
that the document lifecycle rules are being obeyed (whatever they are)
As for backcompat...
My suggestion, should we definitely decide to go this route:
* deprecate the entire DocumentBuilder class on 4x, and remove from trunk
* add this new class with a new name (eg: SolrDocumentBuilder)
* change all existing tests of DocumentBuilder.toDocument to call
SolrDocumentBuilder.toDocument
* on 4x, update DocumentBuilder.toDocument to wrap
SolrDocumentBuilder.toDocument
> Have DocumentBuilder give value collections to the FieldType
> ------------------------------------------------------------
>
> Key: SOLR-4329
> URL: https://issues.apache.org/jira/browse/SOLR-4329
> Project: Solr
> Issue Type: New Feature
> Components: update
> Reporter: David Smiley
> Assignee: David Smiley
> Fix For: 4.2
>
> Attachments: DocumentBuilder.java
>
>
> I'd like to write a multi-value-configured FieldType that can return a
> DocValue Field from its createFields(). Since DocValues holds a single value
> per document for a field, you can only have one. However
> FieldType.createFields() is invoked by the DocumentBuilder once per each
> value being indexed.
> FYI the reason I'm asking for this is for a multi-valued spatial field to
> store its points in DocValues.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
