2009/3/13 Chris Mulligan <[email protected]>: > So I've had a go of replacing the current search with Whoosh. So far it's > actually going fairly well. > > I implemented some IEnvironmentSetup participants to do the setup (and for > upgrading an existing environment). That includes some hacky wiki and ticket > indexers just to get it going to start with. I've replaced the actual search > results logic with Whoosh, and it's working. I need to do a lot to cleanup > with how the results are actually displayed so we get the nice summaries. > > However my question is really a structural one. I see Alec's stream of > conciousness suggestion on Advanced Search and basically like the concept. > However it feels like there's an extra layer. WikiIndexer basically acts as > a WikiChange -> SearchUpdate bridge. It seems like that function would > basically be copied and pasted into all parts of the system that used it, > and if part of the goal is to make search more universal (attachments, repo, > milestones, plugins) it seems like an unfreindly burden on the component > authors.
I don't have a solution for this particular problem, though it sounds vaguely like the general TracObjects scheme. I don't think there's any real way around it with Trac as it stands. For the indexing itself though, I think a separate indexing process would probably be preferable to indexing in a Trac thread, even if the thread isn't the request thread itself. A message queue of some description might be one approach, with the Trac processes pushing references to the objects needing indexing onto the queue, and the indexer pulling them off as it processes. This would allow indexing to be completely asynchronous. But of course, this requires extra setup, and so on. > I don't, however, have a much better suggestion. The only idea would be to > stick the SearchUpdate call into the actual wiki/whatever code, and that > seems to violate the general trac style. > > On Wed, Mar 4, 2009 at 8:02 PM, Alec Thomas <[email protected]> wrote: >> >> I think it's a great idea. >> >> Some discussion has already been had on this subject: >> http://trac.edgewall.org/wiki/AdvancedSearch >> http://trac.edgewall.org/wiki/SearchRefactoring >> >> Implementing a Woosh-specific search shouldn't be too difficult. >> Implement a bunch of XChangeListeners, update index, profit. >> >> Integrating a new search system in a general-purpose manner into the >> core, would be great, but probably quite a bit more work to get it >> right. >> >> 2009/3/5 Chris Mulligan <[email protected]>: >> > Hey Devs, >> > >> > I'm sure many of you have heard of this new search library, Woosh >> > http://whoosh.ca/. It's a pure python search library, and has received >> > some >> > major thumbs up from some of the developers around here. I'm curious if >> > anyone has looked into implementing woosh (or another similar search >> > library >> > like Lucene) for Trac? >> > >> > This is motivated entirely by a local need. As our primary internal >> > tracs >> > grow (thousands of tickets and wiki pages) it's becoming harder and >> > harder >> > for users to find already existing content. They end up making lots of >> > dupes, making the problem even worse the next time. >> > >> > Thanks, >> > Chris >> > >> > > >> > >> >> >> >> -- >> "Life? Don't talk to me about life." - Marvin >> >> > > > > > -- "Life? Don't talk to me about life." - Marvin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
