[Trac] Re: trac search performance?
What about using the Sqlite fts extension modules, http://www.sqlite.org/cvstrac/wiki?p=FtsTwo ? This would seem to be the path of least resistance. FYI, I never heard of these extension until I started playing with Google Gears. On Dec 3, 2007 2:39 PM, Aaron Watters [EMAIL PROTECTED] wrote: btw, I noticed that according to the homepage nucular does not work on NTFS. This would be a show stopper for us. Do you have any info about when/if this will be solved? This seems to be a problem for a lot of people. I will try to solve it soon (using a hack-around). The problem is that in POSIX you can rename or unlink a file that is open by another process, and the system currently relies on this (theoretically). The hack-around would involve adding little marker files whenever an unlink fails that say that file is actually deleted even though it's not and then cleaning them up at some later time I'll see what I can do... Thanks for the reply! -- Aaron Watters === http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=miserable+fact --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: trac search performance?
Ahh, right you are. I guess I'm just so used to the trac-sqlite setup I hadn't thought of the postgres and mysql crowd. On Dec 3, 2007 4:10 PM, Alec Thomas [EMAIL PROTECTED] wrote: On 12/4/07, Doug Douglass [EMAIL PROTECTED] wrote: What about using the Sqlite fts extension modules, http://www.sqlite.org/cvstrac/wiki?p=FtsTwo ? This would seem to be the path of least resistance. FYI, I never heard of these extension until I started playing with Google Gears. The problem is that it's SQLite-specific. Some other DBs have similar functionality, but not all, and we need something that works in the general case. It could also be possible to abstract the system sufficiently that it would use the native FTS then fall back on something else. -- Evolution: Taking care of those too stupid to take care of themselves. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: trac search performance?
On 12/4/07, Doug Douglass [EMAIL PROTECTED] wrote: What about using the Sqlite fts extension modules, http://www.sqlite.org/cvstrac/wiki?p=FtsTwo ? This would seem to be the path of least resistance. FYI, I never heard of these extension until I started playing with Google Gears. The problem is that it's SQLite-specific. Some other DBs have similar functionality, but not all, and we need something that works in the general case. It could also be possible to abstract the system sufficiently that it would use the native FTS then fall back on something else. -- Evolution: Taking care of those too stupid to take care of themselves. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
