[
https://issues.apache.org/jira/browse/SOLR-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640700#action_12640700
]
Hoss Man commented on SOLR-807:
-------------------------------
bq. Make UUID a known type . I mean add a new type to NamedListCodec. This
means bumping up the version of javabin format say version=2. I guess we should
not make this change unless we wish to make some more important changes.
but the crux of the issue isn't specific to UUIDField ... any custom FieldType
people might have is going to encounter this same problem.
If a RequestHandler adds an arbitrary object (not on the legal list) directly
to the response, then the ResponseWriter is certainly at liberty to output that
however it makes sense -- for both XmlResponseWriter and BinaryResponseWriter
that's going to result in a java.util.UUID object, or a chrish.custom.MyBean
object, named 'val' being translated into a string via...
{code}val.getClass().getName() + ':' + val.toString(){code}
...that's fine. But the problem seems to be specifically related to how the
BinaryResponseWriter deals with writing out field values of Documents -- the
FieldType should be used to decide how to render field values.
If we want to have optimized code in the NamedListCodec for efficiently dealing
with the really commons types that's great, but that fallback case, for dealing
with FieldTypes we haven't optimized -- that needs to result in the client
getting some object which isn't just {{val.getClass().getName() + ':' +
val.toString()}} ... at a minimum it should be {{val.toString()}} , but ideally
the FieldType should be able to control of how clients ultimately get the value
of that field. (They don't necessarily need to be able to control how it
should go over the wire, but they should be able to control what the end result
is)
Let's fix the problem (BinaryResponseWriter and field values of arbitrary
FieldTypes) and not the symptom (UUIDFIeld)
How exactly we do this ... i'm not sure. Based on my limited understanding of
the existing code my rough suggestions...
* NamedListCodec could have pass a special TextResponseWriter subclass to the
FieldType's write(TextResponseWriter,...) method, and that TextResponseWriter
could take the same special action NamedListCodec currently takes to
efficiently serialize all of the datatypes in the varies write*(..) methods
* NamedListCodec maintains it's current list of efficient encodings for common
types, but uses FieldType.toExternal() to generate a String to send over the
wire (instead of using toObject) in non-common cases.
* we add a new "{{toSimpleObject(Fieldable)}}" method to FieldType, which would
be documented to say that it must return an object of the "legal" types for a
response ... the default implementation would call toObject(Fieldable), test
the result with a few instanceOf checks and return val.toString() if it doesn't
pass any of them. and start using this method instead of toObject(Fieldable)
when dealing with DocLists.
thoughts?
> UUIDField type cannot be recognized when wt=javabin is used
> -----------------------------------------------------------
>
> Key: SOLR-807
> URL: https://issues.apache.org/jira/browse/SOLR-807
> Project: Solr
> Issue Type: Bug
> Components: clients - java, search
> Affects Versions: 1.3
> Reporter: Koji Sekiguchi
> Priority: Trivial
> Fix For: 1.3.1
>
> Attachments: SOLR-807.patch
>
>
> I'm using UUID via Solrj in my project. When I use javabin (default), I got:
> *java.util.UUID:* 391e3214-4f8e-4abd-aa6b-4f12be79534f
> as the uuid value. But if I use xml, I got:
> 391e3214-4f8e-4abd-aa6b-4f12be79534f
> I think the both of them should return same string.
> program for reproducing the problem:
> {code:java}
> public static void main(String[] args) throws Exception {
> CommonsHttpSolrServer server = new CommonsHttpSolrServer(
> "http://localhost:8983/solr"; );
> SolrQuery query = new SolrQuery().setQuery( "*:*" );
> //server.setParser( new XMLResponseParser() ); // uncomment for wt=xml
> System.out.println( "===== " +
> server.getParser().getClass().getSimpleName() + " =====" );
> QueryResponse rsp = server.query( query );
> SolrDocumentList docs = rsp.getResults();
> for( SolrDocument doc : docs ){
> Object id = doc.getFieldValue( "id" );
> System.out.println( "type = " + id.getClass().getName() + ", id = " +
> id );
> Object timestamp = doc.getFieldValue( "timestamp" );
> System.out.println( "type = " + timestamp.getClass().getName() + ",
> timestamp = " + timestamp );
> }
> }
> {code}
> result for wt=javabin
> {code:title=javabin}
> ===== BinaryResponseParser =====
> type = java.lang.String, id =
> java.util.UUID:391e3214-4f8e-4abd-aa6b-4f12be79534f
> type = java.util.Date, timestamp = Wed Oct 15 00:20:50 JST 2008
> {code}
> result for wt=xml
> {code:title=xml}
> ===== XMLResponseParser =====
> type = java.lang.String, id = 391e3214-4f8e-4abd-aa6b-4f12be79534f
> type = java.util.Date, timestamp = Wed Oct 15 00:20:50 JST 2008
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
