[EMAIL PROTECTED] wrote:
Quoting Daniel Papasian <[EMAIL PROTECTED]>:
Or if you're adding a new field to the schema (perhaps the most common
need for editing schema.xml), you don't need to reindex any documents at
all, right? Unless I'm missing something?
Well, it all depends on if that "field" (not solar/lucene field) exists
on the already indexed material, but that particular field was never
indexed. Lets say that we have a bunch of articles, that has a field
"author" that someone decided that it doesn't need to be in the index.
But then later he changes his mind, and add the author field to the
schema. In this case all articles that has a populated author field
should now be reindexed.
Yeah, I guess the use case I was thinking of was someone who had
multiple different types of content in their index (say, articles,
events, organizations) and when they added a new content type (book
review) if they found the need to add a new field for that content type
(say, publisher) that would only be relevant for that type -- as you're
adding it before any data that would have it was indexed, I believe
you'd be fine making that schema change without reindexing anything.
I suppose if you add a new dynamic field specification that conflicts
with existing fields, reindexing is probably a good idea, but if you're
doing that... well, I probably don't want to know.
I must say that I'm abit confused by these dynamic fields. Can someone
tell me if there is any reasonable use of dynamic fields without having
the "variable type" (for example i for int/sint) in the name?
Well, perhaps this is fulfilling your requirement on a technicality, but
there's always higher order types... Offhand, I can think of things
where you might want to define a dynamic field like *_propername or
*_cost and then you'd be able to use fields like author_propername or
editor_propername, or book_cost or volume_cost or what have you.
Daniel
