On Wed, Feb 17, 2010 at 12:35:11AM -0800, Jeremy Spiegel scratched on the wall:
> In reading http://www.sqlite.org/tempfiles.html, it sounds like a > statement journal file should only be created for statements that > might change multiple rows and which might abort. It should be > possible for sqlite to determine that the above "replace into" would > only affect one row, since it doesn't have any foreign key constraints > pointing into it. Does this represent a bug in sqlite, or is it > just perhaps being overly conservative? While I'm not disputing this specific situation, I would point out that it doesn't require a foreign key to have a REPLACE statement delete more than one row before inserting the new row. For example, if a table has multiple columns with UNIQUE indexes (either automatic from a UNIQUE constraint or manually created), and the new row conflicts with different rows on different columns, then all conflicting rows will be deleted before the insert is allowed to happen. The fact that the situation goes away when you get rid of the second NOT NULL is interesting. I wonder if there is some logic that activates the multi processing if it detects more than one column with any kind of constraint, and not specifically a constraint that might cause a conflict on insert. If this is more of a general purpose code path that is used for other things, that might be the correct thing to do. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Our opponent is an alien starship packed with atomic bombs. We have a protractor." "I'll go home and see if I can scrounge up a ruler and a piece of string." --from Anathem by Neal Stephenson _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
