On Wed, Dec 12, 2012 at 04:28:21PM -0500, Richard Hipp scratched on the wall: > On Wed, Dec 12, 2012 at 4:18 PM, Levi Haskell (BLOOMBERG/ 731 LEXIN) < > lhask...@bloomberg.net> wrote:
> > Intresting, doesn't sqlite3FkCheck() already take these into account? > > > > Yes, it does. But not every home-brew solution to this problem does. > That's why we really ought to handle this inside of PRAGMA integrity_check, > rather than tossing the problem over the wall to applications developers, > as is done now. The whole point of SQLite is to free up app developers to > focus on their application logic by simplifying the storage and persistence > problem. Checking foreign key constraints really ought to be part of what > SQLite does automatically. I like the idea of SQLite handling this, but I'm not sure PRAGMA integrity_check is the right place. Unlike a corrupt database, this is the type of thing that an application can recover from. In order to do that, however, the application needs pretty specific information on the violations that were found. That means whatever is doing this check is likely to return a table with a full report of what was found, including table names, rowids, etc. While the current PRAGMA integrity_check does return errors, they're mostly text error messages that are designed for human consumption. Adding programmatic information in additional columns strikes me as a pretty significant change to the return value of a pretty important PRAGMA. I can also see situations when someone might want to run one set or the other set of checks. Breaking it out, so that these checks are done by a different PRAGMA (integrity_check_v2 ?) seems like a wise idea. Existing applications won't benefit from a new PRAGMA, but existing apps don't know how to react to any errors that might be found. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
