On Tue, 04 Jan 2005 05:54:04 -0500, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
Peter Bartholdsson wrote:Think the topic explains it but there any way to enable recursive triggers? Aka, triggers that run as result of a change by a trigger.
Recursive triggers are on the todo list. They are a prerequisite for the planned implementation of foreign keys.
One stubling block with recursive triggers is that a recursive trigger can result in an infinite loop. I sent out a query a month or so ago requesting ideas on how to detect and deal with infinite loops in recursive triggers. I got a few helpful responses. More input would be appreciated.
Hmm, I don't know how SQLite has been built and if it's feasible but wouldn't a fully adequate solution be to limit the number of recursive calls allowed, either via a PRAGMA or a compiletime constant? I'd consider any code I write that would trigger anything such faulty to begin with so it wouldn't be a limitation of SQLite (granted the limited set high enough). It seems to me a good solution that solves the problem without excessive complexity.
Or rather, how would this solution not be enough?
On Tue, 4 Jan 2005 08:09:05 -0300 (ART), Claudio Bezerra Leopoldino <[EMAIL PROTECTED]> wrote:
I think that a good and simple solution is simply limit the level of recursivity. Maybe 16 nested recursive calls solve 95% of the recursive needs.
On the other hand 16 calls can be quite low, a reason why there should at least be possible to change it. As an example I have an application that stores directory paths in a tree structure and caches the size of each directory to improve startup speed. While most users have only a few folders some have truly scary paths. ;)
This is still of course limited to how many recursive calls SQLite can actually handle.
Regards, Peter Bartholdsson
