[
https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504132
]
Hoss Man commented on SOLR-193:
-------------------------------
these comments are very happhazard, and in the best order i can think of (not
hte order i wrote them)
> Perhaps it would be better to leave out the edge cases and just focus on the
> SolrDocument
...i don't mind big patches that have a lot of things ... it's just weird when
there is a big patch with a lot of stuff and it's not clear what it's for :)
... i was mainly looking for someplace where an UpdateHandler was making a
SolrDocument and then calling build on it.
> Is the only difference between the input Document and output Document that it
> has boosts?
there is some more complexity in Lucene docs because of things like the
Fieldable options but i don't think those really impact a SolrDocument API
since that info is abstracted into the schema and can't be set on a per
document basis.
> Should we have:
> SolrDocument
> + BoostedSolrDocument
BoostedSolrDocument seems to specific to the methods added, and not to the
purpose of the class ... i would call it a "SolrInputDocument"
(IndexSolrDocument is too vague since the term "index" is used so much in the
code base)
The basic structure in the new patch looks fine by the way, no real concerns
from me once the comments are cleaned up (one question: should SolrDocument
implement Map<String,Collection<Object>> ??)
> This is for SOLR-139. to 'modify' a document, you load the existing Document
> - change it -
> then store it back.
>
> These two functions can happily live in a new class, and could be attached to
> SOLR-139.
...oh, right, i forgot about the "update in place" patch .... yeah i don't
think those methods should live in DocumentBuilder (am i alone in thinking
DocumentBuilder should probably be deprecated completely once this stuff is
commited? ... or ... hmmm ... it could probably be subclassed by one that
supports adding a whole SolrInputDocument at once, or one that can start with
an older Document and update it with a new SolrInputDocument ... but we can
worry about that later)
"updating" is a direct example of the type of thing i refered to in LUCENE-778
about why a single Lucene Document class is bad. to support updating you
should have an explicitly means of composing the output class into the input
class ... but in that case you're dealing directly with Lucene Documents -- i
can understand why we would need to modify a Lucene document into a
SolrInputDocument ... but i don't think we really need to worry about the
SolrDocument => SolrInputDocument case right?
> 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-SimpleSolrDocument.patch,
> 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.
