: I had mm (minimum match) blow up at query time with a number
: format exception (this is from memory).
That's a RequestHandler specific request param that can also be specified
as a default/invarient/appended init param ... i'm not sure that SolrCore
could do much to validate that when parsing
: I had silent a error that I can't remember the details of, but it
: was something like putting the str for boost functions outside
: the lst. It didn't blow up, but it was a nonsense config that
: was accepted.
again, there's nothing erroneous about having a str outside of a lst
when specifing
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
:
: : 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.
:
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
On 3/3/07, Ryan McKinley [EMAIL PROTECTED] wrote:
...The rationale with the solrconfig stuff is that a broken config should
behave as best it can. This is great if you are running a real site
with people actively using it - it is a pain in the ass if you are
getting started and don't notice
Bertrand Delacretaz wrote:
On 3/3/07, Ryan McKinley [EMAIL PROTECTED] wrote:
...The rationale with the solrconfig stuff is that a broken config
should
behave as best it can. This is great if you are running a real site
with people actively using it - it is a pain in the ass if you are
I was bit by this, tool. It made getting started a lot harder.
I think I had something outside of an lst instead of inside.
More recently, I got a query time exception from a mis-formatted
mm field.
Right now, Solr accesses the DOM as needed (at runtime) to fetch
information. There isn't much
On 3/3/07, Jed Reynolds [EMAIL PROTECTED] wrote:
If dynamicField definitions are removed from the schema.xml file (and
your fields are not referencing them), does this have the same effect of
disabling unknown-field generation?
Yes. You should get an error if you add a document with a field
: I almost didn't notice the exception fly by because there's s much
: log output, and I can see why I might not have noticed. Yay for
: scrollback! (Hrm, I might not have wanted to watch logging for 4
: instances of solr all at once. Might explain why so much logging.)
FYI: Solr logs a lot
: I spent a long time tracking down an error with a document set with an
: uppercase field name to something configured with a lowercase field.
: Isn't this the kind of error that XML validation is supposed to address?
it could be ... except that:
1) we can't using standard DTD/XSD style
: 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
There still may be a bug that Ryan mentioned about unknown fields
simply being ignored, but that should be fixed if true.
I just looked into this - /trunk code is fine.
I wasn't noticing the errors because the response code is always 200
with an error included in the xml. My code was only
On 3/3/07, Ryan McKinley [EMAIL PROTECTED] wrote:
Is there enough general interest in having error response codes to
change the standard web.xml config to let the SolrDispatchFilter
handle /select?
/select should already use HTTP error codes, right?
-Yonik
On 3/3/07, Yonik Seeley [EMAIL PROTECTED] wrote:
On 3/3/07, Ryan McKinley [EMAIL PROTECTED] wrote:
Is there enough general interest in having error response codes to
change the standard web.xml config to let the SolrDispatchFilter
handle /select?
/select should already use HTTP error codes,
/update
does send 200 even if there was an error.
after SOLR-173 we may want to change the default solrconfig to map
/update so that everything has a consistent error format.
On 3/3/07, Yonik Seeley [EMAIL PROTECTED] wrote:
On 3/3/07, Ryan McKinley [EMAIL PROTECTED] wrote:
Is there enough
For anyone not on the dev list, I just posted:
http://issues.apache.org/jira/browse/SOLR-179
so it is not lost, I also posted Otis' bug report:
http://issues.apache.org/jira/browse/SOLR-180
On 3/3/07, Ryan McKinley [EMAIL PROTECTED] wrote:
But MANY of the SolrExceptions use a status
code '1'.
Hmmm, I did an audit of the exceptions before we entered the incubator, and
I thought I caught all the ones that generated anything out of the 400
and 500 range
and could be thrown during a
On 3/3/07, Yonik Seeley [EMAIL PROTECTED] wrote:
On 3/3/07, Ryan McKinley [EMAIL PROTECTED] wrote:
But MANY of the SolrExceptions use a status
code '1'.
Hmmm, I did an audit of the exceptions before we entered the incubator, and
I thought I caught all the ones that generated anything out of
Chris Hostetter wrote:
: I almost didn't notice the exception fly by because there's s much
: log output, and I can see why I might not have noticed. Yay for
you should be able to configure it to put WARNING and SEVERE messages in a
seperate log file even.
Certainly! I learned to
Hi Jed,
NullPointerException when adding a document w/o the uniqueKey field is
a known bug, and should be fixed shortly.
If the actual schema was null, then that was probably some problem
parsing the schema.
If that's the case, hopefully you saw an exception in the logs on startup?
Anyway, I
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Share
- Original Message
From: Yonik Seeley [EMAIL PROTECTED]
To: solr-user@lucene.apache.org
Sent: Friday, March 2, 2007 10:28:31 AM
Subject: Re: merely a suggestion: schema.xml validator
On 3/2/07, Ryan McKinley [EMAIL PROTECTED] wrote:
The rationale with the solrconfig stuff is that a broken config should
behave as best it can.
I don't think that's what I was actually going for in this instance
(the schema).
I was focused on getting correct stuff to work correctly, and worry
On 3/2/07, Yonik Seeley [EMAIL PROTECTED] wrote:
On 3/2/07, Ryan McKinley [EMAIL PROTECTED] wrote:
The rationale with the solrconfig stuff is that a broken config should
behave as best it can.
I don't think that's what I was actually going for in this instance
(the schema).
I was focused on
Ryan McKinley wrote:
On 3/2/07, Yonik Seeley [EMAIL PROTECTED] wrote:
On 3/2/07, Ryan McKinley [EMAIL PROTECTED] wrote:
The rationale with the solrconfig stuff is that a broken config should
behave as best it can.
I don't think that's what I was actually going for in this instance
(the
On 3/2/07, Jed Reynolds [EMAIL PROTECTED] wrote:
...my first try at defining a schema.xml file was tough because my
only feedback for a long time was NullPointerException from SolrCore
when I was trying to add content...
Can you give us enough information to reproduce the problem? What was
26 matches
Mail list logo
