[
https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504052
]
Hoss Man commented on SOLR-193:
-------------------------------
i'm not sure that i understand a lot of what's going on here ... the basic API
for SolrDocument makes sense to me, but i'm not sure that i understand some of
the methods in SimpleSolrDoc ... what is setDistinctByDefault, or
setDistinctOrderMatters ?
Also, what is the purpose/use of DocumentBuilder.build and
DocumentBuilder.loadStoredFields ... neither seems to be used anywhere ... if
they are not intended for use by existing clients of DocumentBuilder, but new
client code not year written that won't care about any of the existing stateful
methods in DocumentBuilder, perhaps they (the two new methods) should live in
a separate class?
The spirit of DocumentBuilder.build makes sense to me in the context of the
issue title -- but loadStoredFields on the other hand really doesn't make sense
to me at all...
1) DocumentBuilder is only involved in in building Lucene Document objects to
index ... so why have a method in it for converting from a Lucene Document
object to something else?
2) I thought the SolrDocument API was for incoming documents ... why a method
for adding values to it from an existing Lucene Document, or special logic for
looking at stored fields?
3) if the goal is for SolrDocument to be general enough to handle
pre-indexing or post-searching Document representation, then we should not
attempt to model boosts in it ... those should only live in a subclass used for
indexing purposes (Lucene made this mistake early on, and it's caused countless
amounts of confusion to this date) ... the loadStoredFields seems to suffer
from this confusion by trying to access the field boosts of a Lucene Document
that (appears to be) the result of a search --- they don't exist in those
instances of Lucene Documents.
If these methods are not intended for use by existing clients of
DocumentBuilder, but new client code not year written that doesn't care about
any of the existing stateful methods in DocumentBuilder, perhaps they (the two
new methods) should live in a separate class?)
Hmmm... rereading the issue summary and the comments about playing nice with EL
i see the goal is for a generic representation both in a java client sending
docs to and reading docs back from Solr, as well as internally within Solr (or
embedded Solr contexts) ... I think it's a mistake to try and have one single
Interface for all three. At the very least there should be a seperate API for
the indexing side and the query side (because of the boost issue) which can be
subclass/superclass relationships.
I ranted about this in a related Lucene Jira issue (note also the email
discussion linked to from one of my comments in that issue) ...
https://issues.apache.org/jira/browse/LUCENE-778
> General SolrDocument interface to manage field values.
> ------------------------------------------------------
>
> Key: SOLR-193
> URL: https://issues.apache.org/jira/browse/SOLR-193
> Project: Solr
> Issue Type: New Feature
> Reporter: Ryan McKinley
> Attachments: SOLR-193-SolrDocument.patch,
> SOLR-193-SolrDocument.patch, SOLR-193-SolrDocument.patch,
> SOLR-193-SolrDocument.patch, SOLR-193-SolrDocument.patch,
> SOLR-193-SolrDocument.patch
>
>
> In an effort to make SOLR-139 (the "modify" command) more manageable, i
> extracted out a large chunk. This patch adds a general SolrDocument
> interface and includes a concrete implementation (SimpleSolrDoc)
> SOLR-139 needs some way to transport document values independent of the
> lucene Document. This is required for the INCREMENT command and useful for
> modifying documents. SolrDocument is also generally useful for SOLR-20
> - - - - - -
> The one (potentially) controversial part is that I added a function to
> FieldType:
> public Object toExternalValue(Fieldable f);
> This asks each field type to convert its Fieldable into its real type, for
> example IntField.java has:
> public Integer toExternalValue(Fieldable f) {
> return Integer.valueOf( toExternal(f) );
> }
> By default, it returns a string value. If this addition is too much, there
> are other (less clean) ways to handle the INCREMENT command. My real
> motivation for this addition is that it makes it possible to implement an
> embeddable SOLR-20 client that does not need an HTTP connection.
> - - - -
> The SimpleSolrDoc implementation was written for SOLR-20. It needs to play
> nice with EL, so it implements a few extra map function that may not seem
> necessary:
> ${doc.values['name']]} gets a collection
> ${doc.valueMap['name']]} gets a single value for the field
> - - - -
> The tests cover all "toExternalValue" changes in schema.*
> SimpleSolrDoc and DocumentBuilder have 100% test coverage.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
