Re: [Tracker] Anaylsis of Sqlite FTS 3

[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