[KinoSearch] Serialized Schema (was KinoSearch::FieldSpec::text)

[Nathan Kurz]

On 9/6/07, Marvin Humphrey <marvin at rectangular.com> wrote:
>
> On Sep 6, 2007, at 6:57 AM, Peter Karman wrote:
> > natively supported field types make a lot of sense to me.
>
> It would be really nice if FieldSpecs themselves were completely
> serializable.  After the "text" change, we have exactly one fixed
> class def.   I was thinking about adding text::unstored,
> text::unanalyzed, text::unstoredunanalyzed, etc... but that quickly
> gets ridiculous.

I fear I'm a slow student, but why is this ridiculous?  The particular
names you have chosen are little cumbersome (because you are presuming
direct mapping to a subclasses) but aren't there only a few types one
wants to support natively:  text, blob, keyword, number, maybe date,
what else?

Also, my instinct (perhaps because I've only been looking at the
Scorer side) is that these field types are going to be most useful if
they have a corresponding scorer, such that you can do stuff queries
like "keyword_field:tag text_field:word && number_field:<10".  Would
recording the analyzer steps be enough to do this?  If desirable, I
think it would need native semantics.

Nathan Kurz
nate at verse.com

[Apologies for not providing the position passing stuff I promised.
Perhaps tomorrow.]

_______________________________________________
KinoSearch mailing list
KinoSearch at rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch