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 schema).
I was focused on getting correct stuff to work correctly, and worry
about incorrect stuff later :-)
sorry, I was referring to solrconfig.xml... if something goes wrong
loading handlers it continues but prints out some log messages. I
(think) there are code comments somewhere about how it should be ok to
have an error and still keep a working system... I'd like to be able
to configure a "strict" mode so it does not continue.
> The other one that can confuse you is if you add documents with fields
> that are undefined - rather then getting an error, solr adds the
> fields that are defined (it may print out an exception somewhere, but
> i've never noticed it)
Also unintended.
How do you all feel about returning an error when you add a document
with unknown fields?
That sounds like a good option to specify in solrconfig.xml.
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?
I completely understand the appeal of loosely validating XML documents,
of course. However, since adding a document to an index is not a
lightweight operation, adding validation doesn't seem unreasonable. If
writing a schema is required for validation, I'm willing to endure that
step. I can certainly see many instances when components in my system
written by other staff won't fit into my Solr schema. A way to enforce a
schema, strictly, in a dev environment, is entirely appropriate for me.
Jed
