[KinoSearch] fields and Swish3

[Peter Karman]

Marvin Humphrey wrote on 1/12/10 5:21 PM:
> On Tue, Jan 12, 2010 at 04:41:04PM -0600, Peter Karman wrote:
> 
>> It seems like I need a combination of StringType and FullTextType, so
>> that I can have a field that is both analyzed and sortable. 
> 
> In KS svn trunk, FullTextType fields are sortable.  They use the complete
> field value for sorting.

sweet.

> 
> Furthermore, fields no longer need be "indexed" to be "sortable".  The prior
> sort engine built the sort cache at search time by iterating over a Lexicon --
> so to be sortable fields had to be indexed (so that they would be in the
> Lexicon).  The new sort engine builds sort caches at index time using raw
> field values.

that's how Swish-e 2.x does it. That's been a big win for Swish-e; glad to see 
you took that road too.

> 
>> Or, should I accept the limitation of 1 field per name
> 
> The one-to-one mapping of field names to individual field values is deeply
> baked into KS.  I wouldn't rule out composite field types in the future (e.g.
> something like a "GeoPointType" which stored an X/Y coordinate), but I do
> think that we need to accept the idea that there is one value per name.
> 

one-to-one field names is cool as long as FullText is sortable.

>> This really comes into play when I try and apply a RangeQuery, because
>> those require a sortable field.
> 
> Are we good to go now that FullTextType fields can be sortable?
> 

yes! thanks for the quick reply.

Of course, my next question is predictable: when will 0.30 be fully cooked? And, 
how can I help?


-- 
Peter Karman  .  http://peknet.com/  .  peter at peknet.com