Re: [Tracker] Anaylsis of Sqlite FTS 3

["Jamie McCracken" <jamie mccrack googlemail com>]

well using it raw is not an option as its too different and too  inefficient

sqlite fts is not moving very fast (only dfference between FTS2 and FTS3 was a bug fix tot he index structure) and is fairly stable

I will use ifdef directives to mark our changes so hopefully we can easily adapt it to FTS4 when it comes out

we cant move our stuff upstream as it uses glib and is too tracker specific (EG we are storing text contents outside FTS and only using it for an index)

the fork is necessary unfortunately and I will manage it

note we dont need to use a matching version of FTS with sqlite as it uses the standard extensions feature of sqlite

jamie

jamie

2008/9/20 Martyn Russell <martyn imendio com>

Jamie McCracken wrote:
> On Wed, 2008-07-30 at 05:56 +0300, Ivan Frade wrote:
>> Hi Jamie

Hi

>>  This FTS3 sounds great, and could help to remove a lot of "home brew" code.
>>
>>> All the above disadvantages can be sorted by forking FTS 3 and
>>> including:
>>  well, "forking" doesn't sound so good. Specially talking about sqlite
>> that moves very fast. I dont know the technical details but sqlite
>> should have places to connect the parsing functions and scoring
>> algorithms. Something similar to the "collation" functions for the
>> traditional tables. If it didnt have those things, we can think on add
>> them.
>>
>
> it has no ranking at all in their index structure
>
> a fork is necessary to add missing functionality - the code for it is
> pretty small and we would have to inline the source of it even if we
> were not forking as its not built into sqlite so wont be in distros

I have to agree with Ivan. I think forking should always be the last
alternative. We will be missing out on all the improvements that the
SQLite developers make.

If the code is small, it should be easy to just have a patch which we
keep somewhere and apply during the build phase and just keep SQLite
code as imported. GnomeVFS did this sort of thing for some of its
imported libraries. Doing this would also make it easy to upgrade our
SQLite import when we want to update it and fold back fixes.

But before all of this, have you asked the SQLite developers if they
would be interested in a patch from us to add such functionality? I
really think forking should be the last step.

--
Regards,
Martyn