--- Scott Hess <[EMAIL PROTECTED]> wrote:
> S, as far as I can tell, this behaviour changed in October, with
> http://www.sqlite.org/cvstrac/chngview?cn=3470 . Which is before fts2
> even existed! So fts2 has been broken in this way essentially
> forever. *sigh*. [I'm not entirely clear
S, as far as I can tell, this behaviour changed in October, with
http://www.sqlite.org/cvstrac/chngview?cn=3470 . Which is before fts2
even existed! So fts2 has been broken in this way essentially
forever. *sigh*. [I'm not entirely clear why that change introduced
this difference, but it
[Forwarding gist of an offline conversation with Joe.]
Looks about like what my patch looks like. Needs to additionally
handle %_segments.rowid (same problem, but you need to insert more
than 16 docs to see it).
I'm also tossing in some test cases. My patch should be ready this
afternoon.
You can, and I'm working on a patch to do this to see how it might look.
There's the question of how to handle existing tables.
-scott
On 7/17/07, Chris Wedgwood <[EMAIL PROTECTED]> wrote:
On Tue, Jul 17, 2007 at 09:37:43AM -0700, Scott Hess wrote:
> Summary: In sqlite 3.4, running vacuum
Scott, I've attached a possible patch to the ticket.
It seems to work, but I may have missed some something.
Tell me what you think.
--- Scott Hess <[EMAIL PROTECTED]> wrote:
> I've updated the bug with an example of how this breaks fts tables
> (fts1 or fts2). I'm thinking on the problem.
>
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
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
>>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
>The rowid is the standard SQLite rowid, so it does provide an INTEGER
>PRIMARY KEY AUTOINCREMENT column.
>
>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
On 7/16/07, Adam Megacz <[EMAIL PROTECTED]> wrote:
Is there any way to use a INTEGER PRIMARY KEY AUTOINCREMENT on a table
that has FTS2? Specifying it in the obvious manner looks like it
works, but the column just ends up with nulls in it.
In fts tables all columns other than rowid are of
10 matches
Mail list logo
