On Wed, Mar 13, 2013 at 7:36 PM, Dan Kennedy <danielk1...@gmail.com> wrote: > On 03/14/2013 12:09 AM, Dominique Devienne wrote: >> I stumbled upon >> http://stackoverflow.com/questions/60168/in-what-order-are-on-delete-cascade-constraints-processed >> >> Is this just happenstance in this case or will it work every-time there are >> similar "pseudo cycles" that can be "broken" by processing the ON DELETE >> CASCADE in a given order? >> >> If it works every-time, what's the underlying mechanism that guarantees >> that? Some kind of topological sort between tables based on foreign keys? >> Or perhaps the fact that FKs are enforced "lazily", after all rows have >> been deleted? > > In this case, the statement deletes a row from the parent > table. Which increments the counter by 2, as there are now > 2 child rows without a parent. The ON DELETE CASCADE logic > causes it to delete the row from the uncle table, which > decrements the counter. Then the same again for the child > table. The counter is then zero and the statement is committed.
Makes perfect sense. Thank you for this precision. --DD _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
