On Sat, 10 Mar 2018 01:17:38 +0000 Simon Slavin <[email protected]> wrote:
> On 9 Mar 2018, at 7:49pm, John Found <[email protected]> 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 > [email protected] > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users -- http://fresh.flatassembler.net http://asm32.info John Found <[email protected]> _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
