Looks promising! With the me triggers mentioned in http://www.sqlite.org/src/artifact/fdc666a70d5257a64fee209f97cf89e0e6e32b51 , it can be a really time saver. Its awful having to deal with two tables that store a single, split up entity, also the inability to create additional indexes on the text columns (when needed i must make a shadow copy on the real table only to have it indexed)
Any speed comparisons were made on regular+fts tables joined when searching, vs fts4 + external content table triggered in the way described above ? Fabian-40 wrote: > > It seems I finally have some sort of a solution: > > "As of SQLite version 3.7.9, FTS4 supports a new option - "content" > -designed to extend FTS4 to support the creation of full-text indexes > where: > > + > + * The indexed documents are not stored within the SQLite database > + at all (a "contentless" FTS4 table), or > + > + * The indexed documents are stored in a database table created and > + managed by the user (an "external content" FTS4 table). > > > Using this new option I can keep all data together in a regular table, > and use FTS purely as an index. > > I wonder why this new option wasn't mentioned in the changelog of > 3.7.9, but maybe because it's still experimental? > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > -- View this message in context: http://old.nabble.com/FTS4%3A-Datatypes-tp32815033p32818172.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
