This is because fts tables intentionally do not support things like
primary keys. There is the rowid/docid, and there are text columns,
and that is all. If you want to add key support, you can use an
auxiliary table with a one-to-one mapping on docid.
-scott
On Sat, Jan 19, 2008 at 12:33 PM, Andy Goth <[EMAIL PROTECTED]> wrote:
> SQLite version 3.5.4
> sqlite> create virtual table foo using fts3(content, id primary key);
> sqlite> insert or replace into foo values('anything', 1);
> sqlite> insert or replace into foo values('anything', 1);
> sqlite> insert or replace into foo values('anything else', 1);
> sqlite> select * from foo;
> anything|1
> anything|1
> anything else|1
>
> For comparison's sake:
>
> SQLite version 3.5.4
> Enter ".help" for instructions
> sqlite> create table foo (content, id primary key);
> sqlite> insert or replace into foo values('anything', 1);
> sqlite> insert or replace into foo values('anything', 1);
> sqlite> insert or replace into foo values('anything else', 1);
> sqlite> select * from foo;
> anything else|1
>
> Why doesn't inserting a row with a duplicate primary key trigger a conflict?
> Is this part of fts3's design, or is it an oversight? Am I missing
> something?
>
> For now, I will avoid this problem by deleting rows matching the primary key
> before inserting/replacing them.
>
> --
> Andy Goth
> <[EMAIL PROTECTED]>
>
>
> -----------------------------------------------------------------------------
> To unsubscribe, send email to [EMAIL PROTECTED]
> -----------------------------------------------------------------------------
>
>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
