On Sat, 10 Mar 2018 01:17:38 +0000 Simon Slavin <slav...@bigfraud.org> wrote:
> On 9 Mar 2018, at 7:49pm, John Found <johnfo...@asm32.info> wrote: > > > In the current implementation "insert or replace" behave as the foreign > > constraint is deferred. > > But according to documentation, all foreign constraints in SQLite are > > immediate by default. > > John, > > The documentation suggests that in SQLite foreign keys are not deferred by > default. Section 4.2 of > > <https://sqlite.org/foreignkeys.html> > > talks about this and shows how to set up a foreign key to be deferred: > > create table B ( > aid references A(id) on delete cascade DEFERRABLE INITIALLY DEFERRED, > ulti_data) > No difference at all. Because "insert or replace" always works as if the constraint is deferred. "insert or replace" always succeed to delete rows that are referenced by B and defers the constraint enforcement until the end of the internal transaction. But at the end, a new row with the same ID is inserted, so there is no constraint violation anymore. > Assuming you are using atomic commit (not using BEGIN/COMMIT, so SQLite > "inserts" them around that single statement) I /think/ this should allow your > code to work the way you intended. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users -- http://fresh.flatassembler.net http://asm32.info John Found <johnfo...@asm32.info> _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
