response writer 'default' action
The response writers print a debug message when you put a non-standard
value in them:
} else {
// default... for debugging only
writeStr(name, val.getClass().getName() + ':' + val.toString(), true);
}
All the values used in the standard handlers are in the list, so this
is fine. I'm writing some custom handlers where it would be nice to
put an arbitrary object into the response and have it printed out with
toString()
} else {
writeStr(name, val.toString(), true);
}
Of course I could put it into the response with .toString(), but it
would be more convenient to keep it in the response as an Object so
that I can use it later down the chain.
Can we change this behavior?
thanks
ryan
Re: merely a suggestion: schema.xml validator or better schema validation logging
On 3/3/07 1:43 PM, "Chris Hostetter" <[EMAIL PROTECTED]> wrote: > : Right now, Solr accesses the DOM as needed (at runtime) to fetch > : information. There isn't much up-front checking beyond the XML > : parser. > > bingo, and adding more upfront checking is hard for at least two reasons i > can think of... > > 1) keeping a DTD up to date is a pain sa new features are added > 2) the way some options are passed to plugable classes makes it impossible > to validate (ie: tokenizers, caches, etc...) I was thinking of translating the config file into internal config properties when it was read, and logging Solr specific errors then. Things like "I can't load this class" are pretty easy at that poin. DTDs are inadequate and XML Schema is horrid, plus the error messages from either would be not particularly useful. wunder
Re: response writer 'default' action
: All the values used in the standard handlers are in the list, so this
: is fine. I'm writing some custom handlers where it would be nice to
: put an arbitrary object into the response and have it printed out with
: toString()
Keep in mind, there is a contract about what constitutes "Returnable data"
http://lucene.apache.org/solr/api/org/apache/solr/request/SolrQueryResponse.html#returnable_data
...what you're describing would be a modification of that contract.
personaly, i'd prefer we encourage RequestHandler writers to stick to that
contract and unwind their objects themselves so that their RequestHandlers
can be reused with any ResponseWRiter ... but i agree it would be handy to
add a...
public void writeUnknown(String name, Object val, boolean needsEscaping) {
writeStr(name, val.getClass().getName() + ':' + val.toString(),
needsEscaping);
}
...to the base writers so that people could override in subclasss
for special purposes and then call that in the else case.
-Hoss
Re: response writer 'default' action
Keep in mind, there is a contract about what constitutes "Returnable data"
http://lucene.apache.org/solr/api/org/apache/solr/request/SolrQueryResponse.html#returnable_data
That list is not quite up-to-date, it should add:
* Document
* Collection should be changed to: Iterable
* Iterator
...what you're describing would be a modification of that contract.
Yes, I'm suggesting we say what happens if you add an Object not on
the list. I think the most reasonable behavior is to say: "Objects
not contained in this list will be treated as a String using the value
returned from Object.toString()"
personaly, i'd prefer we encourage RequestHandler writers to stick to that
contract and unwind their objects themselves so that their RequestHandlers
can be reused with any ResponseWRiter
how would treating Objects as "toString()" limit what ResponseWriters
could be used? Am i missing something?
The thing that is nice about allowing an Object in the response is
that the you can pull it out later rather then a unwound version. In
my use case, I have functions that pump data into the response, they
are surrounded with at try {} that if something goes wrong checks
their content and does stuff.
Yes, i could figure some other way to do this, but mostly I was
surprised that the writers default to a debugging action rather then a
useful one.
... but i agree it would be handy to add a...
public void writeUnknown(String name, Object val, boolean needsEscaping) {
writeStr(name, val.getClass().getName() + ':' + val.toString(),
needsEscaping);
}
...to the base writers so that people could override in subclasss
for special purposes and then call that in the else case.
Yes, that would be nice.
Re: response writer 'default' action
On 3/4/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
Yes, i could figure some other way to do this, but mostly I was
surprised that the writers default to a debugging action rather then a
useful one.
It was useful to me at the time to try and figure out if I had
everything in the list I needed ;-)
I'm OK with toString() for Object (I don't see it as a big deal either
way, really).
> ... but i agree it would be handy to add a...
>
> public void writeUnknown(String name, Object val, boolean needsEscaping) {
> writeStr(name, val.getClass().getName() + ':' + val.toString(),
needsEscaping);
> }
>
> ...to the base writers so that people could override in subclasss
> for special purposes and then call that in the else case.
>
Yes, that would be nice.
Very expert level use, may change from release-to-release :-)
-Yonik
Re: response writer 'default' action
: That list is not quite up-to-date, it should add: : : * Document Really? ... i guess i missed that one (i thought it had to be in a DocList) : * Collection should be changed to: Iterable : * Iterator Collection changed to Iterable i remember (that was totally backwards compatably) adding Iterator didn't click for me. : Yes, I'm suggesting we say what happens if you add an Object not on : the list. I think the most reasonable behavior is to say: "Objects : not contained in this list will be treated as a String using the value : returned from Object.toString()" i was mainly just pointing out that changes like that affect people who have already written their own ResponseWriters ... i'd prefer not to do that in backwards INcompatible ways without a really good reason. : > personaly, i'd prefer we encourage RequestHandler writers to stick to that : > contract and unwind their objects themselves so that their RequestHandlers : > can be reused with any ResponseWRiter : : how would treating Objects as "toString()" limit what ResponseWriters : could be used? Am i missing something? i was refering to ResponseWriters written for older versions of hte contract: that don't expect anything not on that list. in general, i think it's better if RequestHandlers unwind the object because that way any errors happen well before the writer starts to generate the response (while there is still time to deal with the error, and well before any risk of the HTTP response already being flushed so that we can't change the HTTP status code. besides which a RequestHandler is in a better position to say response.add(obj.toString()) and know that is the right thing to do then a ResponseWriter ... you might have a bug in your RequestHandler that causes it to put hte wrong thing in the response and not understand where the weird string in your response is coming from ... letting hte ResponseWriter throw an error (or return the debuging info it currently does) forces you to do the right thing in your RequestHandler. : The thing that is nice about allowing an Object in the response is : that the you can pull it out later rather then a unwound version. In ...that's what SOlrQueryRequest.getContext() is for, the response should really only be for data you genuniely want returned (unwound into simple primitives so there's less risk of error once your RequestHandler no longer has any control over it) -Hoss
Re: merely a suggestion: schema.xml validator or better schema validation logging
: : > : Right now, Solr accesses the DOM as needed (at runtime) to fetch : > : information. There isn't much up-front checking beyond the XML : > : parser. : I was thinking of translating the config file into internal config : properties when it was read, and logging Solr specific errors then. : Things like "I can't load this class" are pretty easy at that poin. most of that work is done right now when the solrconfig.xml and schema.xml are loaded ... any missing classes should be logged as errors immediately. I'm actaully haven't a hard time thinking of what kinds of "just in time" DOM walking is delayed until request ... all of the feld names are already known, the analyzers are built, the requesthandlers and responsewriters all exist and have been initialized ... what stuff isn't checked until a request comes in? -Hoss
Re: merely a suggestion: schema.xml validator or better schema validation logging
On 3/4/07 3:01 PM, "Chris Hostetter" <[EMAIL PROTECTED]> wrote: > I'm actaully haven't a hard time thinking of what kinds of "just in time" > DOM walking is delayed until request ... all of the feld names are already > known, the analyzers are built, the requesthandlers and responsewriters > all exist and have been initialized ... what stuff isn't checked until a > request comes in? I had (minimum match) blow up at query time with a number format exception (this is from memory). I had silent a error that I can't remember the details of, but it was something like putting the for boost functions outside the . It didn't blow up, but it was a nonsense config that was accepted. wunder
