Hi Chris, sure, you can create an addional field for every field that should support sorting.
In our application we need to do this for all 20 fields. That means me have to create twenty redundant fields just for sorting. That's really an overhead in size and indexing-time. :: using the stored value doesn't help: there can be multiple stored values :: just as easily as there can be multiple tokens. In what situations do you have more than one stored value per field? In our applications we always have one stored value for each field. In such a situation it would be perfect to take these stored values for sorting.... Wouldn't it? Greetings lude On 9/23/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: for years there is the discussion to make lucene able to sort on TOKENIZED : fields. really? .. i've only been on the list since 1.4.3 but i don't remember it being much of a recurring topic. : (e.g. if more then one term is available concatenate the tokens OR use the : stored value for sorting). using the stored value doesn't help: there can be multiple stored values just as easily as there can be multiple tokens. concatenating the tokens is a vague concept that would be very hard to get right in a way that would work genericly: for starters, how do you deal with tokens at the same position? (ie; synonyms) In my experience, the best way to deal with this is for the application using Lucene to decide which fields it wants to sort on, and make a "sortable" version of that field that is indexed by not tokenized -- the application is afterall in teh best position to decide how exactly it wnats to "sort" on the data (ie: should the values be lowercased so the sort is case-insensetive? should certain punctution characters be striped out? etc...) -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
