You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Ryan McKinley (JIRA)" <ji...@apache.org> on 2007/03/20 08:11:32 UTC
[jira] Created: (SOLR-193) General SolrDocument interface to manage
field values.
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
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.
[jira] Commented: (SOLR-193) General SolrDocument interface to
manage field values.
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SOLR-193) General SolrDocument interface to
manage field values.
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504342 ]
Ryan McKinley commented on SOLR-193:
------------------------------------
> 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>> ??)
If the class implements Map, JSTL treats it differently -- for example, ${doc.fieldNames} does not call:
Collection<String> getFieldNames();
it calls: Map.get( "fieldNames" );
this is really annoying! Essentially any real function you add is hidden (unless i'm incompetent in JSTL land...)
This is why I had:
+ ///////////////////////////////////////////////////////////////////
+ // Utility functions to help JSTL (map interface to single field
+ ///////////////////////////////////////////////////////////////////
+
+ public Map<String,Collection<Object>> getValuesMap()
+ {
+ return _fields;
+ }
+
+ public Map<String,Object> getValueMap() {
+ return new Map<String,Object>() {
+ // The only reason we are implementing map!
+ public Object get(Object key) {
+ return getFieldValue( (String)key);
+ }
+
+ // Easily Supported methods
+ public boolean containsKey(Object key) { return _fields.containsKey( key ); }
+ public Set<String> keySet() { return _fields.keySet(); }
+ public int size() { return _fields.size(); }
+ public boolean isEmpty() { return _fields.isEmpty(); }
+
+ // Unsupported operations. These are not necessary for JSTL
+ public void clear() { throw new UnsupportedOperationException(); }
+ public boolean containsValue(Object value) {throw new UnsupportedOperationException();}
+ public Set<java.util.Map.Entry<String, Object>> entrySet() {throw new UnsupportedOperationException();}
+ public Object put(String key, Object value) {throw new UnsupportedOperationException();}
+ public void putAll(Map<? extends String, ? extends Object> t) {throw new UnsupportedOperationException();}
+ public Object remove(Object key) {throw new UnsupportedOperationException();}
+ public Collection<Object> values() {throw new UnsupportedOperationException();}
+ };
+ }
I would still like to include these in the API.
> 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
> Assignee: Ryan McKinley
> Attachments: SOLR-193-SimpleSolrDocument.patch, 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.
[jira] Updated: (SOLR-193) General SolrDocument interface to manage
field values.
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley updated SOLR-193:
-------------------------------
Attachment: SOLR-193-SimpleSolrDocument.patch
Thanks for your feedback Hoss.
I think this one is good to go.
> 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-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.
[jira] Commented: (SOLR-193) General SolrDocument interface to
manage field values.
Posted by "Yosvanys Aponte Báez (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489717 ]
Yosvanys Aponte Báez commented on SOLR-193:
-------------------------------------------
I install solr in window, and when i goto to admin page appear this error
What really happen??
Please some body help me
HTTP ERROR: 500
No se puede compilar la clase para JSP
Error de servlet generado:
17-abr-2007 9:23:37 org.apache.jasper.compiler.Compiler generateClass
GRAVE: Javac exception
Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK
at
org.apache.tools.ant.taskdefs.compilers.CompilerAdapterFactory.getCompiler(C
ompilerAdapterFactory.java:105)
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:929)
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758)
at
org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:382)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:472)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:5
11)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:2
95)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandl
er.java:473)
at
org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:286)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:171)
at org.mortbay.jetty.servlet.Default.handleGet(Default.java:302)
at org.mortbay.jetty.servlet.Default.service(Default.java:223)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandl
er.java:473)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext
java:633)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
at org.mortbay.http.HttpServer.service(HttpServer.java:909)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:820)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:986)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:837)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:245)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
Error de servlet generado:
17-abr-2007 9:23:37 org.apache.jasper.compiler.Compiler generateClass
Error de servlet generado:
GRAVE: Env: Compile:
javaFileName=/C:/DOCUME~1/yaponte/CONFIG~1/Temp/Jetty__8983__solr//org/apach
e/jsp/admin\index_jsp.java
Error de servlet generado:
classpath=/C:/Documents%20and%20Settings/yaponte/Configuraci?n%20local/Temp/
Jetty__8983__solr/webapp/WEB-INF/lib/apache-solr-1.1.0-incubating.jar;/C:/Do
cuments%20and%20Settings/yaponte/Configuraci?n%20local/Temp/Jetty__8983__sol
r/webapp/WEB-INF/lib/lucene-core-nightly.jar;/C:/Documents%20and%20Settings/
yaponte/Configuraci?n%20local/Temp/Jetty__8983__solr/webapp/WEB-INF/lib/luce
ne-highlighter-nightly.jar;/C:/Documents%20and%20Settings/yaponte/Configurac
i?n%20local/Temp/Jetty__8983__solr/webapp/WEB-INF/lib/lucene-snowball-nightl
y.jar;/C:/Documents%20and%20Settings/yaponte/Configuraci?n%20local/Temp/Jett
y__8983__solr/webapp/WEB-INF/lib/xpp3-1.1.3.4.O.jar;C:\DOCUME~1\yaponte\CONF
IG~1\Temp\Jetty__8983__solr;C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\apache-solr-1.1.0-incubating
jar;C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\lucene-core-nightly.jar;C:\D
ocuments and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\lucene-highlighter-nightly.j
ar;C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\lucene-snowball-nightly.jar;
C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\xpp3-1.1.3.4.O.jar;C:\Archiv
os de programa\Java\jre1.5.0_03\lib\ext\dnsns.jar;C:\Archivos de
programa\Java\jre1.5.0_03\lib\ext\localedata.jar;C:\Archivos de
programa\Java\jre1.5.0_03\lib\ext\sunjce_provider.jar;C:\Archivos de
programa\Java\jre1.5.0_03\lib\ext\sunpkcs11.jar;C:\Inetpub\ftproot\apache-so
lr-1.1.0-incubating\example\start.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-i
ncubating\example\lib\org.mortbay.jetty.jar;C:\Inetpub\ftproot\apache-solr-1
1.0-incubating\example\lib\javax.servlet.jar;C:\Inetpub\ftproot\apache-solr
-1.1.0-incubating\example\lib\org.mortbay.jmx.jar;C:\Inetpub\ftproot\apache-
solr-1.1.0-incubating\example\ext\ant.jar;C:\Inetpub\ftproot\apache-solr-1.1
0-incubating\example\ext\jasper-runtime.jar;C:\Inetpub\ftproot\apache-solr-
1.1.0-incubating\example\ext\jasper-compiler.jar;C:\Inetpub\ftproot\apache-s
olr-1.1.0-incubating\example\ext\commons-el.jar;C:\Inetpub\ftproot\apache-so
lr-1.1.0-incubating\example\ext\commons-logging.jar;C:\Inetpub\ftproot\apach
e-solr-1.1.0-incubating\example\ext\mx4j-remote.jar;C:\Inetpub\ftproot\apach
e-solr-1.1.0-incubating\example\ext\mx4j-tools.jar;C:\Inetpub\ftproot\apache
-solr-1.1.0-incubating\example\ext\mx4j.jar
Error de servlet generado:
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\lib\org.mortbay.j
etty.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\lib\javax.s
ervlet.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\lib\org.m
ortbay.jmx.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\a
nt.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\jasper-ru
ntime.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\jasper
-compiler.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\co
mmons-el.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\com
mons-logging.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext
\mx4j-remote.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext
\mx4j-tools.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\
mx4j.jar
cp=C:\Documents%20and%20Settings\yaponte\Configuraci?n%20local\Temp\Jetty__8
983__solr\webapp\WEB-INF\lib\apache-solr-1.1.0-incubating.jar
cp=C:\Documents%20and%20Settings\yaponte\Configuraci?n%20local\Temp\Jetty__8
983__solr\webapp\WEB-INF\lib\lucene-core-nightly.jar
cp=C:\Documents%20and%20Settings\yaponte\Configuraci?n%20local\Temp\Jetty__8
983__solr\webapp\WEB-INF\lib\lucene-highlighter-nightly.jar
cp=C:\Documents%20and%20Settings\yaponte\Configuraci?n%20local\Temp\Jetty__8
983__solr\webapp\WEB-INF\lib\lucene-snowball-nightly.jar
cp=C:\Documents%20and%20Settings\yaponte\Configuraci?n%20local\Temp\Jetty__8
983__solr\webapp\WEB-INF\lib\xpp3-1.1.3.4.O.jar
cp=C:\DOCUME~1\yaponte\CONFIG~1\Temp\Jetty__8983__solr
cp=C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\apache-solr-1.1.0-incubating
jar
cp=C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\lucene-core-nightly.jar
cp=C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\lucene-highlighter-nightly.j
ar
cp=C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\lucene-snowball-nightly.jar
cp=C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\xpp3-1.1.3.4.O.jar
cp=C:\Archivos de programa\Java\jre1.5.0_03\lib\ext\dnsns.jar
cp=C:\Archivos de programa\Java\jre1.5.0_03\lib\ext\localedata.jar
cp=C:\Archivos de programa\Java\jre1.5.0_03\lib\ext\sunjce_provider.jar
cp=C:\Archivos de programa\Java\jre1.5.0_03\lib\ext\sunpkcs11.jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\start.jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\lib\org.mortbay.j
etty.jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\lib\javax.servlet
jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\lib\org.mortbay.j
mx.jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\ant.jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\jasper-runtim
e.jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\jasper-compil
er.jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\commons-el.ja
r
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\commons-loggi
ng.jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\mx4j-remote.j
ar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\mx4j-tools.ja
r
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\mx4j.jar
work dir=C:\DOCUME~1\yaponte\CONFIG~1\Temp\Jetty__8983__solr
extension dir=C:\Archivos de programa\Java\jre1.5.0_03\lib\ext
srcDir=C:\DOCUME~1\yaponte\CONFIG~1\Temp\Jetty__8983__solr
include=org/apache/jsp/admin/index_jsp.java
-----Mensaje original-----
De: Ryan McKinley (JIRA) [mailto:jira@apache.org]
Enviado el: miércoles, 18 de abril de 2007 5:58
Para: solr-dev@lucene.apache.org
Asunto: [jira] Updated: (SOLR-193) General SolrDocument interface to manage
field values.
[
https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugi
n.system.issuetabpanels:all-tabpanel ]
Ryan McKinley updated SOLR-193:
-------------------------------
Attachment: SOLR-193-SolrDocument.patch
Damn dyslexia! I can hardly see the difference even when its pointed out.
thanks eric.
SOLR-193-SolrDocument.patch, SOLR-193-SolrDocument.patch,
SOLR-193-SolrDocument.patch
extracted out a large chunk. This patch adds a general SolrDocument
interface and includes a concrete implementation (SimpleSolrDoc)
lucene Document. This is required for the INCREMENT command and useful for
modifying documents. SolrDocument is also generally useful for SOLR-20
FieldType:
example IntField.java has:
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.
play nice with EL, so it implements a few extra map function that may not
seem necessary:
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Universidad 2008
Del 11 al 15 de febrero del 2008
Palacio de Convenciones. La Habana. Cuba.
Sitio Web: http://www.universidad2008.cu
> 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
>
>
> 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.
[jira] Commented: (SOLR-193) General SolrDocument interface to
manage field values.
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482438 ]
Yonik Seeley commented on SOLR-193:
-----------------------------------
> toExternalValue(Fieldable f)
"external" value sort of already means the human-readable serialized textual representation.
What about something like toObject() which would return the appropriate Java object (such as Integer, Long, Date, etc)?
> 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
>
>
> 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.
[jira] Updated: (SOLR-193) General SolrDocument interface to manage
field values.
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley updated SOLR-193:
-------------------------------
Attachment: SOLR-193-SolrDocument.patch
One other note:
the "id" field in the test schema.xml was a multiValued field. I changed it to single valued.
> 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
>
>
> 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.
[jira] Updated: (SOLR-193) General SolrDocument interface to manage
field values.
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley updated SOLR-193:
-------------------------------
Attachment: SOLR-193-SolrDocument.patch
applies with trunk, fixed some spelling...
> 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.
[jira] Assigned: (SOLR-193) General SolrDocument interface to
manage field values.
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley reassigned SOLR-193:
----------------------------------
Assignee: Ryan McKinley
> 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
> Assignee: Ryan McKinley
> Attachments: SOLR-193-SimpleSolrDocument.patch, 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.
[jira] Updated: (SOLR-193) General SolrDocument interface to manage
field values.
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley updated SOLR-193:
-------------------------------
Attachment: SOLR-193-SolrDocument.patch
yes:
Object toObject( Fieldable );
is better.
> 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
>
>
> 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.
e-mail faux pas
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Apr 18, 2007, at 10:23 AM, Yosvanys Aponte Báez wrote:
> I install solr in window, and when i goto to admin page appear this
> error
> What really happen??
careful with replying to e-mails. you replied to an automated e-
mail and added a comment to our issue tracker. when starting a new
thread, create a new e-mail DO NOT reply to a previous one. only
reply to JIRA e-mails if they are actually comments on the issue
itself. also, you e-mailed the solr-dev list when your question was
a general user list question. i'll let you start a new thread on the
solr-user list for this topic.
Erik
RE: [jira] Updated: (SOLR-193) General SolrDocument interface to manage field values.
Posted by Yosvanys Aponte Báez <ya...@isch.edu.cu>.
I install solr in window, and when i goto to admin page appear this error
What really happen??
Please some body help me
HTTP ERROR: 500
No se puede compilar la clase para JSP
Error de servlet generado:
17-abr-2007 9:23:37 org.apache.jasper.compiler.Compiler generateClass
GRAVE: Javac exception
Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK
at
org.apache.tools.ant.taskdefs.compilers.CompilerAdapterFactory.getCompiler(C
ompilerAdapterFactory.java:105)
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:929)
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758)
at
org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:382)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:472)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:5
11)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:2
95)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandl
er.java:473)
at
org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:286)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:171)
at org.mortbay.jetty.servlet.Default.handleGet(Default.java:302)
at org.mortbay.jetty.servlet.Default.service(Default.java:223)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandl
er.java:473)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext
java:633)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
at org.mortbay.http.HttpServer.service(HttpServer.java:909)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:820)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:986)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:837)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:245)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
Error de servlet generado:
17-abr-2007 9:23:37 org.apache.jasper.compiler.Compiler generateClass
Error de servlet generado:
GRAVE: Env: Compile:
javaFileName=/C:/DOCUME~1/yaponte/CONFIG~1/Temp/Jetty__8983__solr//org/apach
e/jsp/admin\index_jsp.java
Error de servlet generado:
classpath=/C:/Documents%20and%20Settings/yaponte/Configuraci?n%20local/Temp/
Jetty__8983__solr/webapp/WEB-INF/lib/apache-solr-1.1.0-incubating.jar;/C:/Do
cuments%20and%20Settings/yaponte/Configuraci?n%20local/Temp/Jetty__8983__sol
r/webapp/WEB-INF/lib/lucene-core-nightly.jar;/C:/Documents%20and%20Settings/
yaponte/Configuraci?n%20local/Temp/Jetty__8983__solr/webapp/WEB-INF/lib/luce
ne-highlighter-nightly.jar;/C:/Documents%20and%20Settings/yaponte/Configurac
i?n%20local/Temp/Jetty__8983__solr/webapp/WEB-INF/lib/lucene-snowball-nightl
y.jar;/C:/Documents%20and%20Settings/yaponte/Configuraci?n%20local/Temp/Jett
y__8983__solr/webapp/WEB-INF/lib/xpp3-1.1.3.4.O.jar;C:\DOCUME~1\yaponte\CONF
IG~1\Temp\Jetty__8983__solr;C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\apache-solr-1.1.0-incubating
jar;C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\lucene-core-nightly.jar;C:\D
ocuments and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\lucene-highlighter-nightly.j
ar;C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\lucene-snowball-nightly.jar;
C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\xpp3-1.1.3.4.O.jar;C:\Archiv
os de programa\Java\jre1.5.0_03\lib\ext\dnsns.jar;C:\Archivos de
programa\Java\jre1.5.0_03\lib\ext\localedata.jar;C:\Archivos de
programa\Java\jre1.5.0_03\lib\ext\sunjce_provider.jar;C:\Archivos de
programa\Java\jre1.5.0_03\lib\ext\sunpkcs11.jar;C:\Inetpub\ftproot\apache-so
lr-1.1.0-incubating\example\start.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-i
ncubating\example\lib\org.mortbay.jetty.jar;C:\Inetpub\ftproot\apache-solr-1
1.0-incubating\example\lib\javax.servlet.jar;C:\Inetpub\ftproot\apache-solr
-1.1.0-incubating\example\lib\org.mortbay.jmx.jar;C:\Inetpub\ftproot\apache-
solr-1.1.0-incubating\example\ext\ant.jar;C:\Inetpub\ftproot\apache-solr-1.1
0-incubating\example\ext\jasper-runtime.jar;C:\Inetpub\ftproot\apache-solr-
1.1.0-incubating\example\ext\jasper-compiler.jar;C:\Inetpub\ftproot\apache-s
olr-1.1.0-incubating\example\ext\commons-el.jar;C:\Inetpub\ftproot\apache-so
lr-1.1.0-incubating\example\ext\commons-logging.jar;C:\Inetpub\ftproot\apach
e-solr-1.1.0-incubating\example\ext\mx4j-remote.jar;C:\Inetpub\ftproot\apach
e-solr-1.1.0-incubating\example\ext\mx4j-tools.jar;C:\Inetpub\ftproot\apache
-solr-1.1.0-incubating\example\ext\mx4j.jar
Error de servlet generado:
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\lib\org.mortbay.j
etty.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\lib\javax.s
ervlet.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\lib\org.m
ortbay.jmx.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\a
nt.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\jasper-ru
ntime.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\jasper
-compiler.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\co
mmons-el.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\com
mons-logging.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext
\mx4j-remote.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext
\mx4j-tools.jar;C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\
mx4j.jar
cp=C:\Documents%20and%20Settings\yaponte\Configuraci?n%20local\Temp\Jetty__8
983__solr\webapp\WEB-INF\lib\apache-solr-1.1.0-incubating.jar
cp=C:\Documents%20and%20Settings\yaponte\Configuraci?n%20local\Temp\Jetty__8
983__solr\webapp\WEB-INF\lib\lucene-core-nightly.jar
cp=C:\Documents%20and%20Settings\yaponte\Configuraci?n%20local\Temp\Jetty__8
983__solr\webapp\WEB-INF\lib\lucene-highlighter-nightly.jar
cp=C:\Documents%20and%20Settings\yaponte\Configuraci?n%20local\Temp\Jetty__8
983__solr\webapp\WEB-INF\lib\lucene-snowball-nightly.jar
cp=C:\Documents%20and%20Settings\yaponte\Configuraci?n%20local\Temp\Jetty__8
983__solr\webapp\WEB-INF\lib\xpp3-1.1.3.4.O.jar
cp=C:\DOCUME~1\yaponte\CONFIG~1\Temp\Jetty__8983__solr
cp=C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\apache-solr-1.1.0-incubating
jar
cp=C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\lucene-core-nightly.jar
cp=C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\lucene-highlighter-nightly.j
ar
cp=C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\lucene-snowball-nightly.jar
cp=C:\Documents and Settings\yaponte\Configuraci?n
local\Temp\Jetty__8983__solr\webapp\WEB-INF\lib\xpp3-1.1.3.4.O.jar
cp=C:\Archivos de programa\Java\jre1.5.0_03\lib\ext\dnsns.jar
cp=C:\Archivos de programa\Java\jre1.5.0_03\lib\ext\localedata.jar
cp=C:\Archivos de programa\Java\jre1.5.0_03\lib\ext\sunjce_provider.jar
cp=C:\Archivos de programa\Java\jre1.5.0_03\lib\ext\sunpkcs11.jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\start.jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\lib\org.mortbay.j
etty.jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\lib\javax.servlet
jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\lib\org.mortbay.j
mx.jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\ant.jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\jasper-runtim
e.jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\jasper-compil
er.jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\commons-el.ja
r
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\commons-loggi
ng.jar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\mx4j-remote.j
ar
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\mx4j-tools.ja
r
cp=C:\Inetpub\ftproot\apache-solr-1.1.0-incubating\example\ext\mx4j.jar
work dir=C:\DOCUME~1\yaponte\CONFIG~1\Temp\Jetty__8983__solr
extension dir=C:\Archivos de programa\Java\jre1.5.0_03\lib\ext
srcDir=C:\DOCUME~1\yaponte\CONFIG~1\Temp\Jetty__8983__solr
include=org/apache/jsp/admin/index_jsp.java
-----Mensaje original-----
De: Ryan McKinley (JIRA) [mailto:jira@apache.org]
Enviado el: miércoles, 18 de abril de 2007 5:58
Para: solr-dev@lucene.apache.org
Asunto: [jira] Updated: (SOLR-193) General SolrDocument interface to manage
field values.
[
https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugi
n.system.issuetabpanels:all-tabpanel ]
Ryan McKinley updated SOLR-193:
-------------------------------
Attachment: SOLR-193-SolrDocument.patch
Damn dyslexia! I can hardly see the difference even when its pointed out.
thanks eric.
> 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
>
>
> 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.
Universidad 2008
Del 11 al 15 de febrero del 2008
Palacio de Convenciones. La Habana. Cuba.
Sitio Web: http://www.universidad2008.cu
[jira] Updated: (SOLR-193) General SolrDocument interface to manage
field values.
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley updated SOLR-193:
-------------------------------
Attachment: SOLR-193-SolrDocument.patch
Damn dyslexia! I can hardly see the difference even when its pointed out.
thanks eric.
> 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
>
>
> 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.
[jira] Commented: (SOLR-193) General SolrDocument interface to
manage field values.
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (SOLR-193) General SolrDocument interface to manage
field values.
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley updated SOLR-193:
-------------------------------
Attachment: SOLR-193-SimpleSolrDocument.patch
Here is a much much smaller patch that only adds the SolrDocument *class* and BoostableSolrDocument subclass.
We can work through the other bits later, but this would be sufficient for SOLR-20
It is a quick eclipes refactoring, so the comments may not make sense. I'll check that over in better detail after you all get a chance to look at it...
> 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.
[jira] Commented: (SOLR-193) General SolrDocument interface to
manage field values.
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504095 ]
Ryan McKinley commented on SOLR-193:
------------------------------------
For background. This class has functionality used for other issues including SOLR-104, SOLR-139. For a while i tried keeping the functionality in different patches, but it became too much of a nightmare to maintain. Perhaps it would be better to leave out the edge cases and just focus on the SolrDocument interface now...
> what is setDistinctByDefault, or setDistinctOrderMatters ?
>
These options let you say if the field values should be backed by a Map<String> or a List<String>, the DistinctOrderMatters says if it should be Map<String> or LinkedHashMap<String>
These were useful for SOLR-104 when you SQL join a table and may get duplicate rows, but only want the distinct values to keep fields.
Now that you point it out, (and there is a good chance it will be in trunk soon) It would make more sense to implement these features as different subclasses of SimpleSolrDocument.
> Also, what is the purpose/use of DocumentBuilder.build and DocumentBuilder.loadStoredFields
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.
> 2) I thought the SolrDocument API was for incoming documents ...
I hope it is also useful for modifying existing Documents and transforming incoming/outgoing documents (but I'll raise that issue later ;)
> 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.
>
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.
Is the only difference between the input Document and output Document that it has boosts?
Should we have:
SolrDocument
+ BoostedSolrDocument
or
SolrDocument
+ IndexSolrDocument
Any thoughts on the common use case where I want to pull a document out of the index (no boosts) change it, then put it back? Do i need to make a new class and copy all the fields? Should SOLR-20 be able to index a SolrDocument (no boosts) as well as a BoostedSolrDocument? I think so...
Thanks for looking at this!
> 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.
[jira] Updated: (SOLR-193) General SolrDocument interface to manage
field values.
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley updated SOLR-193:
-------------------------------
Attachment: SOLR-193-SolrDocument.patch
applies cleanly with trunk
> 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
>
>
> 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.
[jira] Resolved: (SOLR-193) General SolrDocument interface to
manage field values.
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley resolved SOLR-193.
--------------------------------
Resolution: Fixed
Fix Version/s: 1.3
moved DocumentBuilder issues to SOLR-262
> 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
> Assignee: Ryan McKinley
> Fix For: 1.3
>
> Attachments: SOLR-193-SimpleSolrDocument.patch, 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.
[jira] Updated: (SOLR-193) General SolrDocument interface to manage
field values.
Posted by "Erik Hatcher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Erik Hatcher updated SOLR-193:
------------------------------
Comment: was deleted
> 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
>
>
> 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.
[jira] Commented: (SOLR-193) General SolrDocument interface to
manage field values.
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (SOLR-193) General SolrDocument interface to manage
field values.
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley updated SOLR-193:
-------------------------------
Attachment: SOLR-193-SolrDocument.patch
> 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
>
>
> 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.
[jira] Commented: (SOLR-193) General SolrDocument interface to
manage field values.
Posted by "Erik Hatcher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489092 ]
Erik Hatcher commented on SOLR-193:
-----------------------------------
The latest patch has a typo:
public Document bulid....
should be "build".
> 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
>
>
> 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.