[
https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504100
]
Yonik Seeley commented on SOLR-193:
-----------------------------------
> This sounds fine. We should *defiantly* solve any know problems with the
> Lucene document interface.
> Just using an interface (rather then a concrete class) will be a huge help.
I know this runs contrary to common java OO wisdom, but interfaces can really
suck.
They don't hurt the *consumer* of a class, but cause major headaches for the
*provider*, trying to evolve an interface and still provide backward
compatibility (it's pretty much impossible).
In Lucene, where we have had a class (like Analyzer), it was trivial adding new
functionality like getPositionIncrement(). If it had been an interface, it
would have been impossible without breaking all the custom analyzers out there.
Where we have had interfaces, and added a new method, we simply broke some
peoples code.
So if it's something that a customer might possibly subclass, a class used as
an interface is a much better option.
If it's internal, or package projected, or something where you *really* need
multiple inheritance, then an interface is fine.
> 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.
