lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Date Wed, 21 Feb 2007 07:35:57 GMT

: > en if i wanted to be able to use
: > an option on field foo for some docs and not on others i'd have to
: > have
: > foo_optOFF and foo_optON ... then anytime i wanted to search on
: > "foo" i'd
: > have to use a booleanquery without a coord factor across both.
: I'm trying to think of an example where that would actually come into
: play.  What are some of the options you'd turn on and off?  Norms?
: Tokenization?

it could be anything ... maybe i only care about termvectors for
editorials in a collection that contains editorials, news items, etc...

: IIUC, that's a third objection in addition to your two from the
: previous discussion.  The other two were "evolving" indexes, and what
: you described as "dynamically typed fields" but what I would call
: "multi-dimensional data".

evolving indexes is a big issue i hadn't thought of my last message,
but definitely important...

: KinoSearch's Schema scheme allows you to add new fields, but you
: can't take any away or change any existing defs  -- so you're able to
: evolve, but only within fairly tight constraints.  I can't think of

...yeah, i would find that... frustrating.  it would require downtime when
making a lot of upgrades that i currently can do on the fly.

: aspect "good enough" and we're moving on.  I don't think it's really
: any worse than what we have now -- where field defs persist, stored
: in field infos files, etc, and the resolution of conflicts can bite

the biggest differnece is that the field infos aren't globals, so as
segments merge and old segments get deleted old data (and field info)
vanishes into hte ether ... i take advantage of that a lot when planning
upgrades ... many types of field changes can be made in Solr by deploying
the schema.xml reindexing slowly over as long as it takes (which the index
is live and serving queries) then deploying the application changes that
take advantage of the new field options.

: The multi-dimensional data problem is the one I'm most interested in

i believe yonik already elaborated on that and gave you some good ideas.

the other situation i brought up in that thread from way back was
something Solr doesn't currently have a good solution for: one
field value for display, but other values (in the same field) for
searching ... likewise indexing one field value for sorting, but storing
several field values.

the workarround for this of course is to use multiple field names:
title, title_sort, title_search, etc...


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message