Joe Wilson <[EMAIL PROTECTED]> wrote:
>
> The following question is purely for curiosity's sake - I don't
> advocate doing this... I just want to get a better understanding
> of the sqlite3 file format.
>
> Let's assume the most trivial case - a table without indexes of
> any kind (implicit or
> > >DELETE sqlite_master WHERE type='f';
> >
> > Will all the btree pages orphaned at rootpage for these rows
> > not be recyclable until you run a full VACUUM?
> But if you delete the record for a regular table or index from
> the sqlite_master table using the "writable_schema" backdoor,
On Tue, 2007-07-10 at 16:02 -0700, Joe Wilson wrote:
> --- [EMAIL PROTECTED] wrote:
> > "Scott Hess" <[EMAIL PROTECTED]> wrote:
> > > 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
> > >DELETE sqlite_master WHERE type='f';
> >
> > Will all the btree pages orphaned at rootpage for these rows
> > not be recyclable until you run a full VACUUM?
>
> Yes - but the virtual fts1 table doesn't have any btree pages!
Fair enough. I wasn't sure what was going on behind the scenes.
On 7/10/07, Joe Wilson <[EMAIL PROTECTED]> wrote:
--- [EMAIL PROTECTED] wrote:
> "Scott Hess" <[EMAIL PROTECTED]> wrote:
> > 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
--- [EMAIL PROTECTED] wrote:
> "Scott Hess" <[EMAIL PROTECTED]> wrote:
> > 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.
> >
>
> I probably shouldn't tell
"Scott Hess" <[EMAIL PROTECTED]> wrote:
> 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.
>
I probably shouldn't tell you this, but
There is a pragma:
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
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.
Ok that's exactly what I was asking. Thanks!
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
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
Right, but what I'm asking is:
If version 1.0 of my program uses Sqlite with *only* fts1, and then I
upgrade users to version 2.0 of my program which uses *only* fts3, can my
version 2.0 code (which is using sqlite that only has fts3) safely delete
the original fts1 table created by version 1.0
On Thu, 2007-07-05 at 21:08 -0700, Dave Brown wrote:
> I am considering using FTS for a new feature. My question is:
>
> - If I use fts1 (or fts2) now, and then a new version of fts comes out which
> is not backwards compatible, will I at least be able to upgrade users by
> simply deleting the
I am considering using FTS for a new feature. My question is:
- If I use fts1 (or fts2) now, and then a new version of fts comes out which
is not backwards compatible, will I at least be able to upgrade users by
simply deleting the old FTS table and re-building it using the new FTS
system?
In
14 matches
Mail list logo
