Chris Mulligan wrote: > On Mar 23, 2009, at 11:19 AM, Christian Boos wrote: > > >> Looks like a good start, once I get the full code I'll try it! >> > > Thanks. Here's the full diff I should have had earlier: > http://trac.edgewall.org/attachment/wiki/AdvancedSearch/trac_whoosh_integration_20090323.diff > > . Someone can delete the earlier one (20090321c.diff). >
Ok, got it working. It searches ;-) >> However, there are already some remarks I want to do based on this >> first >> patch: >> - I don't think it's a good idea to make whoosh a mandatory >> requirement, it should stay optional >> - Therefore the current db select/like based search code should be >> kept >> somewhere, probably refactored as the fallback search backend >> >> Of course, when whoosh is available, the WhooshSearchSystem should >> certainly become the default ISearchBackend. A ISearchBackend >> interface >> could have the methods you gave to the public API of SearchSystem in >> your patch, plus a search(query) method and probably also a >> search_syntax_help() method for describing the search query syntax. >> > > I understand your concerns here. I, personally, disagree. I think that > the concerns about dependencies are valid, but that the wins out weigh > the losses. I also think that a reasonable python only dependency > that's worked fine for me in a number of odd environments isn't a big > deal. The cost (in increased lines of code, complexity, decreased > performance and difficulty in future work) is real, and every > individual decision to add, rather than replace, is actually hurting > the project in the long run. I think this doesn't need to be all or nothing, here. One scenario could be that we introduce the whoosh search support in say 0.12, and if all goes well, meaning everybody is happy with the new dependency, we drop the db fallback search in 0.13. So we replace, but without disruption. Starting the way you did by replacing the db search with the new whoosh search is fine by me. Once it has stabilized, we can make the search system modular the way I suggested above and re-add the db based search as a fallback, before integrating in trunk. Er, by the way, are you interested by a sandbox branch? > That's a bit of a tangent though, sorry! > Suffice it to say that I want better search in Trac, and I don't (yet) > see a strong reason to not switch. > Did those "odd environments" include Windows? ;-) I saw some issues with the index locking: WindowsError: [Error 183] Cannot create a file when that file already exists: ...n-search\\trac\\search_index\\_MAIN_LOCK' That was during my trials to get the tests running, but nevertheless this could be indicative of more fundamental issues. Trac is a somehow complex application with both multithreading and multiprocessing going on, so things like locking and dead locks might be sensitive. Something to keep an eye on it... >> Besides, I don't know if you had already taken a look at the >> SearchRefactoring page, but at least one idea which I think is worth >> reusing from there is the relative ranking of fields (e.g. a match in >> the "keywords" fields is worth n times a match in the description, for >> example). Is it possible to do this with whoosh? >> > > This is possible, and it already does some of that by default. I > haven't tried to tweak this yet, just been focused on getting it > working. > Another thing is that whoosh presents the search results by order of relevance (I suppose).That's fine but it would be nice to also support ordering by most recent first, again a kind of "backward compatible" mode. -- Christian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
