I've updated the bug with an example of how this breaks fts tables
(fts1 or fts2). I'm thinking on the problem.
http://www.sqlite.org/cvstrac/tktview?tn=2510
Summary: In sqlite 3.4, running vacuum with fts2 or fts1 tables can
break the table if you've done any deletions.
I'll try to add more constraints to the summary today,
-scott
On 7/17/07, Scott Hess <[EMAIL PROTECTED]> wrote:
WTH! Wow, this is a very unexpected change. I must have not been
paying attention at some point.
-scott
On 7/17/07, Ralf Junker <[EMAIL PROTECTED]> wrote:
>
> >>The standard way to have non-TEXT information associated with rows in
> >>an fts table would be a separate table which joins with the fts table
> >>on rowid.
> >
> >I have not tested this, but if the FTS2 rowid is the standard SQLite rowid,
I believe that it will be affected by VACUUM change of rowids recently reported on
this list? If so, could this be fixed?
>
> VACUUM does modify FTS2 rowids. Here is the test:
>
> drop table if exists a;
>
> create virtual table a using fts2 (t);
>
> insert into a (t) values ('one');
> insert into a (t) values ('two');
> insert into a (t) values ('three');
>
> select rowid, * from a;
>
> delete from a where t = 'two';
> vacuum;
>
> select rowid, * from a;
>
> Unfortunately there is no workaround since table a is auto-generated by the
FTS2 module. Created ticket #2510.
>
>
> -----------------------------------------------------------------------------
> To unsubscribe, send email to [EMAIL PROTECTED]
> -----------------------------------------------------------------------------
>
>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
