lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <>
Subject Re: Namespaces in response (SOLR-1586)
Date Wed, 09 Dec 2009 19:27:51 GMT
Hi Hoss,

> : ...unless things have changed since hte last time i looked, all of the
> : "out of the box" response writers call "toString()" on any object they
> : don't understand.  So the best way to move forward in a flexible manner
> : seems like it would be to add a new "GeoPoint" object to Solr, which
> : toStrings to a simple "-34.56,67.89" for use by existing response writers
> : as a string, but some newer smarter response writer could output it in
> : some more sophisticated manner.
> The caveat to that, now that i've skimmed SOLR-1586, is that it currently
> only applies to objects "added" to the SolrQueryResponse (or one of hte
> containers in it) datastructure that the ResponseWriter's "walk"
> themselves ... because of the back-ass-wards way we have FieldTypes write
> their values directly to an XMLWriter or a TextWriter the idea of using an
> object that stringifies itself as needed doesn't really apply very well

I think it's rather powerful. You insulate the following variations into 1
single place to change them (FieldType):

* output representation
* indexing
* validation

To remove this from FieldType would be to strew the same functionality
across multiple classes, which doesn't make sense IMHO.

> ... and it won't unless we switch all of the ResponseWRiters to follow the
> BinaryResponseWriter model of using FieldType.toObject(...) to get the
> field value as an "obejct" that can be sent over the wire -- then the
> existing XmlResponseWriter, and the Text ResponseWriters, can call
> toString() on Objects they doesn't understand, and some
> newer/hipper/cooler response writers that understand georss can do fancier
> things with it.

In the long run, this might be nice, and +1 on getting there in the long
run. In the short, a compromise is to allow namespacing on fields in the
existing XmlWriter, which is allowed anyways, whether by oversight or not.


Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Phone: +1 (818) 354-8810
Adjunct Assistant Professor, Computer Science Department University of
Southern California, Los Angeles, CA 90089 USA

View raw message