On Fri, Sep 6, 2013 at 6:21 AM, James K. Lowden <jklow...@schemamania.org>wrote:
> That's perfectly good SQL. SQLite is simply not executing the > update atomically. > > Anyone tempted to protest may be forgetting "atomic" means more than > "all or nothing". It also means the DBMS may execute the transaction > however it sees fit, at the cost of ensuring that constraints remain in > effect upon commit but *only* upon commit. ... > Constraints hold for the whole database at all times whenever the user > can see the data. Any update is valid if it can logically be applied > and leave the database in a state consistent with its declared > constraints. > FWIW, in the circumstances of the thread below, SQLite does behave as you described it should in this new UPDATE use-case, i.e. SQLite copes with temporarily invalid states provided the final state is valid. So it's not necessarily a philosophical design decision, but maybe an implementation issue, which is perhaps fixable. My $0.02, before a more authoritative answer. http://sqlite.1065341.n5.nabble.com/Order-of-ON-DELETE-CASCADE-specified-in-SQLite-td67681.html _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
