[KinoSearch] fields and Swish3

[Peter Karman]

First some history.

A Swish-e 2.x index allows for 2 kinds of config constructs, analogous
to the fields in a KS schema. In Swish-e these are called MetaNames and
PropertyNames.

A MetaName is the context in which a token occurs. MetaNames are
equivalent to the KS FullTextType. They are analyzed and stored.

A PropertyName is an arbitrary value. There are 3 types of
PropertyNames: strings, ints and dates (the latter 2 stored identically
but formatted in output differently). A PropertyName is equivalent to
the KS StringType. It is stored and sortable but not analyzed.

Here's my problem. It is possible in Swish-e to define a MetaName 'foo'
and a PropertyName 'foo' and have them co-exist quite happily. An example:

 <doc>
  <foo>hello world</foo>
 </doc>

That would be parsed something like:

 Token 'hello' pos 1 MetaName 'foo'
 Token 'world' pos 2 MetaName 'foo'

And the string 'hello world' stored under the PropertyName 'foo' for
later sorting and retrieval for display.

In KS, there is only 1 field per name, and I've run up against some
headaches in how to construct the KS schema to work like Swish-e does.
It seems like I need a combination of StringType and FullTextType, so
that I can have a field that is both analyzed and sortable. Or, should I
accept the limitation of 1 field per name, and simply come up with an
internal naming convention that creates a schema with 'foo_meta' and
'foo_prop' and then when a user asks for 'foo', pick the appropriate
field name for the actual requested. Or...?

This really comes into play when I try and apply a RangeQuery, because
those require a sortable field.

Ideas?

tia,
pek
-- 
Peter Karman  .  http://peknet.com/  .  peter at peknet.com