Excerpts from William Morgan's message of Sat Sep 12 12:47:14 -0400 2009: > Reformatted excerpts from Rich Lane's message of 2009-09-10: > > I thought it was, but it turns out that unless you explicitly add AND > > operators Xapian will OR terms over the same field such that > > "label:foo label:bar" gives you the union instead of the intersection. > > Ok. I only ask because I'm considering how to present the Xapian index > option in 0.9---the options are to not say anything about it, to force > everyone to switch to it, or anywhere in between.
Yeah, we do need the query behavior to be reasonable before advertising the Xapian index. What's your timeline on 0.9? > > We could fix this by patching Xapian to make this behavior > > configurable, or we could come up with an index-agnostic simple query > > language that doesn't support boolean operators. > > The former sounds easier to me. Especially since it seems like this is > something Xapian should have... Agreed that Xapian should have this, and I'll probably implement it. We still need to support people using older Xapian versions though. Whether this means a log message telling them to use explicit ANDs in their query, or automatically transforming simple-enough queries into what we think they actually want, I don't know. I'll also need to add a workaround for the earlier Xapian bug before this index gets wider usage. As far as which index to make the default, Ferret has the advantage of being installable as a gem dependency. I think this ease of installation is important enough to block Xapian for now, unless someone can create a Xapian gem. There's been interest in this before: http://article.gmane.org/gmane.comp.search.xapian.devel/1408/ _______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
