If you have an fts1 table f, you could drop f_term and f_content, but
you won't be able to drop f itself. So you would have to name the
fts2 version of f something else, like f2.
It might be reasonable to allow some sort of modified drop for such
cases. Perhaps something like:
DROP VIRTUAL TABLE f;
If applied to an fts1 table, this would leave f_term and f_content
behind. So, if you really wanted to, you could code something like:
BEGIN;
DROP VIRTUAL TABLE IF EXISTS f;
DROP TABLE IF EXISTS f_term;
DROP TABLE IF EXISTS f_content;
COMMIT;
While I think this is a reasonable thing to have in there, I worry
that it exposes a little to much of how things work internally - lots
of rope there for hanging yourself! But it's pretty general-purpose.
I think it would be nice to understand the motivation of the original
question. The biggest motivator for upgrading from fts1 to fts2 (or
future fts3) would seem to be performance for larger datasets, which
somewhat implies that keeping fts1 compiled in shouldn't be a big
issue. Transitioning from fts1 to fts2 would generally imply that
you'd need the fts1 code in order to read the fts1 table in order to
build the fts2 version. Understanding the use cases around this might
be worthwhile.
Another solution with minor potential would be to break the fts
implementations between a full implementation and a migration-only
implementation. The full implementation would be exactly what we have
right now, while a migration-only implementation would be something
which the newer version could use to migrate data forward and drop the
old table. Right now, given an fts1 table f, you might do something
like:
BEGIN;
CREATE TABLE f_tmp(content TEXT);
INSERT INTO f_tmp (rowid, content) SELECT rowid, content FROM f;
DROP TABLE f;
CREATE VIRTUAL TABLE f USING fts2(content);
INSERT INTO f (rowid, content) SELECT rowid, content from f_tmp;
DROP TABLE f_tmp;
COMMIT;
My suggestion would be something along the lines of:
SELECT fts2_upgrade('f');
This could use the migration implementation of fts1 to create an fts2
table with all the same data and clean everything up behind itself.
I'm not entirely certain this would work, it might need additional
hackery (specifically, I'd have to check on whether you can call
sqlite3_declare_vtab outside of the xCreate/xConnect methods).
-scott
On 7/10/07, Samuel R. Neff <[EMAIL PROTECTED]> wrote:
Even without having FTS1 loaded, can't you delete the *_content and *_term
tables directly and that would be effectively the same as deleting the
virtual table?
Sam
-------------------------------------------
We're Hiring! Seeking a passionate developer to join our team building
products. Position is in the Washington D.C. metro area. If interested
contact [EMAIL PROTECTED]
On 7/9/07, Scott Hess <[EMAIL PROTECTED]> wrote:
>
> If you have not compiled in fts1, and try to drop an fts1 table,
> you'll get an error. I don't think you'll get a crash, but sqlite
> will simply not know how to deal with the table.
>
> I can think of two ways to deal with this. When builidng a new
> version, you could just leave the fts1 code in place. Otherwise, you
> could put the fts1 table in an attached database, which you could
> delete using filesystem operations when you upgrade.
>
> I would recommend just having both fts1 and fts2 available. If you're
> super-concerned about code size, you could pretty easily strip out all
> of the interesting code from fts1.c and leave only enough to
> successfully drop tables. A little more aggressive would be to leave
> enough code to do read-only queries without the fulltext index (useful
> for pulling all the content data across to fts2).
>
> [Let me know if I misread your question.]
>
> -scott
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
