Enough rants, do we have a spec for BetterSearch, or should I go about dreaming one up? We've been working on it and 2.4 will include BetterSearch ;-). How
On Wed, May 25, 2005 at 01:57:03PM -0700, Corey Burger wrote: that will go down is unclear at this point. I've outlined some methods on the 2.4 scratch pad TODO list: http://wiki.liblime.com/doku.php?id=koha24rmnotes (under "Searching" there are some links to ideas we've had) Chris committed some basic Plucene textual database scripts for Koha into HEAD (CVS for 'development stuff') and I've created a Plucene index and got the searching up and running on NPL's 150,000 biblio database. Unfortunately, based on my initial tests, Plucene doesn't offer much in the way of speed (which is one of the biggest problems at the moment): with NPL's data it often took 14-15 seconds to return a list of items which matched the terms used. I haven't completely given up on Plucene yet as we may not be optimizing the indexes and there may be some ways to get more speed out of it. The second option suggested by Indradg is Namazu which is also a full text indexing/search engine but I haven't had a chance to play with it yet. I still think full text indexes are the way to go as they would allow much more flexibility than SQL affords. So this is an example where we've got some overlap between 'design' and 'new features'. Corey, if you've got some ideas for how searching could be improved, please let us know (you can email the list or just edit the scratch pad I alluded to earlier) -- in the meantime, I'll try to get a sample of Namazu up and running so we can test it out. Does anyone else have searching ideas? -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Koha ILS, Mambo Intranet, DiscrimiNet Filter jmf@liblime.com | Full Demos at http://liblime.com | 1(888)KohaILS