On 12/18/2014 04:16 PM, Paul wrote:
Hi, Dan.
On 12/18/2014 02:41 PM, Paul wrote:
I want to confirm that issue is fixed for me.
Thanks again, Dan!
Please ignore this update, patch fixes this problem as well.
I want to add even more input for this issue.
I understand why there is implicit savepoint, when I remove row from 'parent'
table.
But why is this also true for a 'child' table when I perform 'INSERT OR
REPLACE'?
Removing FK reference disables journal growth. I don't understand...
At the end of the day my head was so big that I, having some ten different test
cases,
have errourneously confirmed that 'INSERT OR REPLACE' is fixed also, by running
wrong test.
But sadly it isn't. Here, I'll drop my test program again, for clarity.
I don't think there is an easy fix for this one. The statement journal
is required, as SQLite may need to reinstate rows deleted by the REPLACE
processing if the FK constraint fails.
To fix this properly, it probably needs to use a more sophisticated data
structure than the statement journal. Which would complicate things
some. But at the moment it seems like SAVEPOINT and very large
transactions don't work well together.
I understand. I guess, I'll have to stick to UPDATE <-> INSERT.
Thank you for taking your time.
Just out of curiosity, I want to ask one more question.
How can FK constraint fail if I am removing (replacing) row from the 'child'
table?
The FK constraint can fail because a new row is being inserted into the
child table. The reason statement rollback may be required is because
any replaced rows will be removed before SQLite has a chance to figure
out if the INSERT actually does violate the PK constraint.
Dan.
Best regards,
Paul
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
