Why not a pragma option that toggles the option to the bag populated? If the pragma is not set, things run as expected. If the pragma is set, keep the bag.
Another option for those that link directly to the engine is at each violation counter up, and another for each violation counter down, add something to the API that would allow the program outside SQLite to link to so it can decide what to do with the errors at finalization. Maybe not run anything internally, just pass the buck to the calling software and let it deal with the problem? On Tue, Nov 17, 2015 at 10:29 PM, Richard Hipp <drh at sqlite.org> wrote: > On 11/17/15, Yuri <yuri at rawbw.com> wrote: > > > > Don't keep the bag, keep only one integer ID of the first failed > > constraint. > > Therein lays the rub: there is no way to tell which (if any) FK > constraint has failed until you have run the operation to the end and > checked them all. Remember, an FK constraint is allowed to be > violated during a transaction, as long as the violation is resolved > before the end of the transaction. > > With CHECK, and UNIQUE, and NOT NULL constraints, you do know that the > constraint has failed right away. And for those constraints, SQLite > does provide more detail about exactly which constraint failed. But > for FK constraints, you never know if a constraint that is failing > right now might be resolved before the end of the transaction. > > -- > D. Richard Hipp > drh at sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
