[
https://issues.apache.org/jira/browse/SOLR-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pieter Berkel updated SOLR-196:
-------------------------------
Attachment: SOLR-196-PHPResponseWriter.patch
This patch updates the PHPResponseWriter original written by Paul Borgermans
and integrates the serialized PHP response writer (renamed to
PHPSerializedResponseWriter to avoid name clashes) originally authored by Nick
Jenkin in SOLR-275. See
http://www.nabble.com/PHP-Response-Writer-for-Solr-tf4140580.html for some
discussion on this implementation.
I've made minimal code changes to JSONwriter in order to reducing the amount of
code-duplication, specifically replacing all static writes of array and map
structure tokens with methods:
public void writeMapOpener(int size) throws IOException,
IllegalArgumentException { writer.write('{'); }
public void writeMapSeparator() throws IOException { writer.write(','); }
public void writeMapCloser() throws IOException { writer.write('}'); }
public void writeArrayOpener(int size) throws IOException,
IllegalArgumentException { writer.write('['); }
public void writeArraySeparator() throws IOException { writer.write(','); }
public void writeArrayCloser() throws IOException { writer.write(']'); }
The size parameter has been introduced specifically for PHPSerializedWriter
(where the output format explicitly requires the size of the array / map to be
set) and is currently ignored by all other response writers. In cases where
the size is not trivial to calculate (e.g. an Iterable object), it is set to
-1. Classes extending JSONwriter that require a valid (non-negative) size
value must overload certain methods (i.e. writeArray() and writeDoc()) to
calculate size correctly. It would also be a good idea to check for invalid
size values in writeMapOpener() and writeArrayOpener() and throw a
IllegalArgumentException if so.
Some other changes I've made to the PHPWriter code from SOLR-196:
1) Removed a lot of code duplicated from JSONwriter.
2) Updated writeStr() to use StringBuilder.
Some other changes I've made to the PHPSerializedWriter code from SOLR-275:
1) Removed some uneccessary duplicate code.
2) Changed key type written by writeArray() from String to int (since they are
suppose to be numeric indicies).
3) Updated writeStr() - serialized php strings don't need to be escaped (it
seems to rely only on the specified string size value) and size needs be
specified in bytes not characters (some Unicode characters were causing
problems when using String.length() to calculate size, can someone please
sanity check this code?).
I've tested both PHPWriter & PHPSerializedWriter and they both seem to output
valid PHP data, it would be great if people could also test them to ensure they
work in their environments. JSONWriter also seems to be fine and although I
didn't test the Python or Ruby writers, I assume they are unaffected (can
anyone confirm?).
Additionally, I've moved PythonWriter and RubyWriter from
JSONResponseWriter.java to PythonResponseWriter.java and
RubyResponseWriter.java respectively.
I noticed that while each Writer specifies a content type value (e.g.
CONTENT_TYPE_JSON_UTF8, CONTENT_TYPE_PYTHON_ASCII) the value returned by
getContentType() is generally CONTENT_TYPE_TEXT_UTF8 or
CONTENT_TYPE_TEXT_ASCII. This is not a big deal and I guessed this allows the
output to be easily displayed in a browser, however it would be quite useful to
have the actual content type value set so that client applications can
determine the response format encoding and process it accordingly without
relying on access to the original "wt" query paramater.
> A PHP response writer for Solr
> ------------------------------
>
> Key: SOLR-196
> URL: https://issues.apache.org/jira/browse/SOLR-196
> Project: Solr
> Issue Type: New Feature
> Components: clients - php, search
> Reporter: Paul Borgermans
> Attachments: SOLR-192-php-responsewriter.patch,
> SOLR-196-PHPResponseWriter.patch
>
>
> It would be useful to have a PHP response writer that returns an array to be
> eval-ed directly. This is especially true for PHP4.x installs, where there is
> no built in support for JSON.
> This issue attempts to address this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
