Hi folks, I'm trying to integrate fulltext search into my primarily Ruby project. Initially, I'd discovered Ferret, and I see that David is updating the git repository periodically. After that, I discovered the whole plan to merge KinoSearch and Ferret into Lucy, so I have to admit I'm a bit confused--especially given the time elapsed since that announcement (although I did read some of the list archives about the licensing/IP issues, so can understand).
I'd hoped it would be easy to integrate Ferret into my project because of the way that it allows separate, field-based indexing. However, I'm a bit puzzled why there's no way to actually get more information about the search hits than the document ID and a score. I tried to look through the recent KinoSearch documentation to see if it (and therefore lucy) are also going to have this limitation, but I don't know Perl, and I have a bit of a hard time figuring out exactly what's going on. If it was C, C++, Ruby, Python, Java, C# or even a few other obscure languages, I might have better luck. ;) Anyway, what I want to do is index a bunch of structures - essentially Ruby Hash objects - with named values and be able to know at least which of the fields actually matched the search query. Ideally, I'd also like to have the offset and length of the match so I could do highlighting on the original data and not have to store everything effectively twice. I'm only a few days into learning Ferret, and it had looked like it would fit the bill for my immediate - and I do mean "immediate" need. However, now that I've discovered this, I'm entertaining alternatives. With that background in mind, I have the following questions: 1) Can lucy store multi-field "documents" a la Ferret? 2) Can lucy give me the match result information I'm looking for within each document as part of the search hit information? 3) How would you relate the completeness/stability of the core C library and Ruby bindings? Any information, answers or suggestions would be really appreciated. Cheers, ast -- Andrew S. Townley <[email protected]> http://atownley.org
