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 <[EMAIL PROTECTED]> > 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 >
_______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
