| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Only do this if we need to load the FTS5 module, sqlite3 might have
been compiled with SQLITE_OMIT_LOAD_EXTENSION, which will make things
go very wrong (poking NULL vfuncs in a 0'ed out sqlite3_api_routines)
at runtime.
This facility must be enabled if we need to load our FTS module, so
bail out at configure time if it's not there.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our old stale copy of the FTS3/4 module is now deleted, replaced by
a shinier FTS5 embedded module. If at configure time we detect that
SQLite doesn't offer the FTS5 module, we will load our own, just as
we used to do with FTS4.
FTS5 brings a few differences in the ways it's meant to be extended,
the tokenizer has been updated to cope with the differences. Also,
FTS5 offers no offsets() builtin function, nor matchinfo() which we
used to implement ranking. It offers though ways to implement
additional functions, and builtin rank support which can be tweaked
to achieve the same functional results than we did.
Other than that, the ways to interact with the FTS virtual table
are roughly similar to those in FTS4, insertions and deletions have
been updated to do things the FTS5 way.
Since it's not worth to bump the database format (data is reproducted
from the journal, so we drop some embedded data such as
nie:plainTextContent), the nco:hobby property has been modified to
no longer be fulltext indexed, AFAIK there's no users ever setting/
accessing that, and the FTS properties change will trigger the
regeneration of the FTS view and virtual tables, resulting in a
seamless update to FTS5.
However, we don't leave completely unscathed from the fts3_tokenizer()
change. Since the older FTS3/4 tokenizer is not registered, we can't
just drop the older FTS table. So it is left dangling and never
accessed again, in favor of the newer fts5 table. This is obviously
not a problem when creating the database from scratch.
In the way, a few bugs were found. per-property weights in ranking
were being given in a scrambled way (although stable across database
generations). And deletion of FTS properties (or entire rows) could
result in the tokens not being fully removed from the FTS table,
resulting in confused searches. These are now fixed.
Impact to users of tracker should be none. All the FTS Sparql-to-SQL
translation has been updated to just use FTS5 syntax and tables.
|
| |
|
|
|
|
|
| |
There's places where CFLAGS is modified/restored while LDFLAGS is left
untouched, both should be saved/restored at the same time.
https://bugzilla.gnome.org/show_bug.cgi?id=742186
|
| |
|
|
|
| |
This isn't perfect, we're really not strict now with compiler arguments
passed, but we still get some warnings sadly
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This is after finding out that some platforms or versions of GCC don't support
flags like -Wmaybe-uninitialized
The attributes.m4 is stolen from systemd who stole it from xine-lib.
The CFLAGS used for Vala based sources and C only sources are printed in the
summary in configure now too. While it may look like we use more flags for
Vala based sources, we don't it's just -Wall with some flags omitted.
|
| |
|
|
|
|
| |
This is to avoid checking for the FTS features in cross-compilation situations
where the check will fail and we've previously done the check anyway (knowing
it works). We use M4 caching for this.
|
| |
|
|
|
|
|
|
|
|
| |
If vala is recent enough, the "sed" operation is not needed.
Also, run the sed trick only once on the file.
Vala version is checked via new m4 function.
Removed the .gir from the CLEANFILES. It must be cleaned only when
the library it comes from is cleaned.
|
| | |
|
| | |
|
|
|
Older versions of libtool fail to create the m4 directory if it does
not exist yet. So add m4 to git to make ./autogen.sh work for those
cases.
|
