As the guy who wrote PayloadHelper, what I really imagined was using
Lucene's vint, etc. stuff, but that was a bit more refactoring wise.
It can be handy for some payloads, but it is still on the app
developer to know what was put in the payload. What this means in
terms of Solr is still up in the air. No one has worked through what
adding payloads means yet.
On Apr 4, 2008, at 8:48 PM, Chris Hostetter wrote:
: There is a PayloadHelper class in Lucene that has decode/encode
float and
: int methods. Any ideas on how Payloads might be uniformly decoded
into
: something readable/debugable from the gui? I think bytes to
String will give
: enough of a clue to be helpful.
I've never really looked at PayloadHelper, but if i were tasked with
trying to find a way to display in HTML an arbitrary byte[] that may
or
may not be a String, i would start by attempting a String
conversion, if
that succeds *and* all chars in the resulting String are "printable" (
ie: Character.isDefined(c) && ! Character.isISOCOntrol(c)) then
display
the first N chars (where N is some reasonable max size to
display) ... if
not, then just display the first N characters of the hex string
representing the byte[].
It might be overkill, but the other possibility would be to add
<payloadInspector> config option to <fieldType> ... it could be a
class
used solely for debugging purposes, and could be declared at arbitrary
points in the <tokenfilter> chain (indicating that from this point on,
this is how to display the payload) or completely outside of the
<analyzer> when using standalone Analyzers (or when the payload
structure
is identicle for hte entire <tokenfilter> chain)
-Hoss
