Re: [sqlite] Is there any way to enable recursive triggers?
Sandy Ganz wrote: This doesn't sound right, I have seen the problem that linux will not use the allocated memory until it is touched, but doesn't the memory manger keep track ultimatly of all allocations (in the kernel which as all encompassing knowledge of allocations) which might include things that have not yet been written too? In some of the apps that I wrote I saw the behaviour that I This is intentional. It has all the information it needs, but it doesn't want to fail, since the apps allocating the memory may not need it all simultaneously. As I recall, FreeBSD behaves the same way. could not allocate more ram and malloc fails, but never really noticed if it fails on memory that has not been touched. I do remember in TOP not seeing allocations happen until it was cleared (memset). For the critical stuff I preallocate and mlock() allocated memory to force it into ram for most of the server processes, but other processes, have run out of ram at allocation time, so I'm not sure that it won't fail just on allocation (all on linux 2.4x btw). Good food for thought... Been a while since I last thought about this issue, but if I remember correctly, you get a malloc() failure if the OS is unable to allocate another page of memory for allocation overhead, and a success if it can allocate that but doesn't have enough swap space left to write to all of it. If you need to be sure that you detect out-of-memory conditions when allocating, you need to write to it immediately and catch any signals, OS exceptions, or whatever the target platform uses. -- http://www.velocityvector.com/ | http://www.indie-games.com/ http://www.classic-games.com/ | http://glmiller.blogspot.com/ "If my forgeries looked as bad as the CBS documents, it would have been 'Catch Me In Two Days'" -- Frank Abagnale, Jr.
RE: [sqlite] Is there any way to enable recursive triggers?
This doesn't sound right, I have seen the problem that linux will not use the allocated memory until it is touched, but doesn't the memory manger keep track ultimatly of all allocations (in the kernel which as all encompassing knowledge of allocations) which might include things that have not yet been written too? In some of the apps that I wrote I saw the behaviour that I could not allocate more ram and malloc fails, but never really noticed if it fails on memory that has not been touched. I do remember in TOP not seeing allocations happen until it was cleared (memset). For the critical stuff I preallocate and mlock() allocated memory to force it into ram for most of the server processes, but other processes, have run out of ram at allocation time, so I'm not sure that it won't fail just on allocation (all on linux 2.4x btw). Good food for thought... Sandy -Original Message- From: Henry Miller [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 04, 2005 12:37 PM To: sqlite-users@sqlite.org Subject: RE: [sqlite] Is there any way to enable recursive triggers? On 1/4/2005 at 12:13 Sandy Ganz wrote: >What OS does not return NULL or an exception when malloc() fails or is out >of memory? OS/2. Linux kernels < 2.6. I think Windows does this too, but I'm not sure. Its harder than you might think to implement, because most OSes don't allocate memory until you WRITE to it. There are programs that take advantage of this by mallocing lots of memory, but only using a small amount. Think of large sparse arrays, you allocate a lot of memory, but only use a few bytes scattered over it. In order to implement malloc that fails the system needs to refuse to give you memory, even though it knows about unused memory (that some other process has reserved but not touched yet). Of course when malloc does not fail there are a host of other problems, eventually the OS just stops your process.
RE: [sqlite] Is there any way to enable recursive triggers?
On 1/4/2005 at 12:13 Sandy Ganz wrote: >What OS does not return NULL or an exception when malloc() fails or is out >of memory? OS/2. Linux kernels < 2.6. I think Windows does this too, but I'm not sure. Its harder than you might think to implement, because most OSes don't allocate memory until you WRITE to it. There are programs that take advantage of this by mallocing lots of memory, but only using a small amount. Think of large sparse arrays, you allocate a lot of memory, but only use a few bytes scattered over it. In order to implement malloc that fails the system needs to refuse to give you memory, even though it knows about unused memory (that some other process has reserved but not touched yet). Of course when malloc does not fail there are a host of other problems, eventually the OS just stops your process.
RE: [sqlite] Is there any way to enable recursive triggers?
What OS does not return NULL or an exception when malloc() fails or is out of memory? Sandy -Original Message- From: Jay [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 04, 2005 12:06 PM To: sqlite-users@sqlite.org; [EMAIL PROTECTED] Subject: Re: [sqlite] Is there any way to enable recursive triggers? One poster mentioned some OS's will not let you know when you're out of RAM (malloc() never fails). That might be difficult! --- Darren Duncan <[EMAIL PROTECTED]> wrote: > If possible, SQLite should also manage memory so that it has the > resources necessary to roll back the infinite recursion and carry on > as normal; SQLite should not crash from an infinity error. = - "Lord Tarlington gazed upon the crazed Egyptian hieroglyphics on the walls of the ancient tomb of the petrified pharaoh, he vowed there would be no curse on him like on that other Lord, unless you count his marriage to Lady Tarlington who, when the lost treasure was found, will be dumped faster than that basket in the bulrushes." Melissa Rhodes - The Castles of Dereth Calendar: a tour of the art and architecture of Asheron's Call http://www.lulu.com/content/77264 __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com
Re: [sqlite] Is there any way to enable recursive triggers?
One poster mentioned some OS's will not let you know when you're out of RAM (malloc() never fails). That might be difficult! --- Darren Duncan <[EMAIL PROTECTED]> wrote: > If possible, SQLite should also manage memory so that it has the > resources necessary to roll back the infinite recursion and carry on > as normal; SQLite should not crash from an infinity error. = - "Lord Tarlington gazed upon the crazed Egyptian hieroglyphics on the walls of the ancient tomb of the petrified pharaoh, he vowed there would be no curse on him like on that other Lord, unless you count his marriage to Lady Tarlington who, when the lost treasure was found, will be dumped faster than that basket in the bulrushes." Melissa Rhodes - The Castles of Dereth Calendar: a tour of the art and architecture of Asheron's Call http://www.lulu.com/content/77264 __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com
Re: [sqlite] Is there any way to enable recursive triggers?
Regarding the risk of infinite loops with triggers ... I believe that SQLite's default case should be to simply let resources define the limits, and stop only when there simply aren't the resources to continue. As with most programming languages, it should be the user's responsibility to not write infinite recursion or iteration in the first place. If the user is doing something that looks like infinite recursion at a casual glance, then we should trust they know what they are doing. The main thing that SQLite should be responsible for is ensuring that any errors in SQL that the user writes will not corrupt the database. If SQLite runs out of resources, then it should terminate and roll back the actions that the trigger did and/or the entire transaction, such as would happen if a unique value or primary key constraint was violated. If possible, SQLite should also manage memory so that it has the resources necessary to roll back the infinite recursion and carry on as normal; SQLite should not crash from an infinity error. Similarly, note that SQLite could run out of resources for many other reasons besides infinite user recursion, so the latter should simply be handled as an instance of the former. So keep it simple and don't try to second-guess the user in the general case. Your code will be by far the simplest. That said, you could add some code for common special cases if you want to give the user a more friendly error message and recover from the situation faster. But these should only be special cases, and not add much complexity to the code. You *could* add a pragma that defines a hard limit for recursion, but that should be possible to disable and/or set to an extremely high number such that the resource limits kick in first. The hard limit would be an optional limiter, and not the main fallback limiter. On a separate matter, in your linked list example, this could be handled a lot more effectively if you supported simple iteration, such as a while-loop; that way, the memory footprint is the same small amount regardless of how many items are in the linked list. Note that the SQL standard defines triggers as being more or less the same as stored procedures as to what they can contain. -- Darren Duncan
RE: [sqlite] Is there any way to enable recursive triggers?
Out of curiosity, why not allow recursion, but start returning warnings from sqlite3_step indicating that the query is recursive (perhaps once it has crossed some predefined recursion count)? As one post mentioned, every programming language allows you to shoot yourself in the foot with recursion, and for precisely the reasons that make a hard limit seem somewhat unpalatable. Although, if hard limits are imposed, I would prefer a runtime defined limit, so that I can change the limit based on the needs of the application, without having to recompile the sqlite libraries. --Keith ** - Ever notice how 'big' isn't, compared to 'small'? - Sounds like a Wookie; acts like mad cow. - I'm not a professional; I just get paid to do this. - Rules for programming: 1. Get it working, right? 2. Get it working right. - Things I've learned about multithreaded programming: 123... PPArrvooottieedcc ttm ueelvvteeirrtyyhtt rhheiianndgge dwi hnpi rctohhg eri aslm omscitanalgt iowcbh,je engceltvo ebwrah lip,co hso srci abonlt ehb .ee^Nr waicscee snsoetd 'aotb jtehcet -slaomcea lt'il m^Ne from two or more threads ** -Original Message- From: Jeremy Hinegardner [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 04, 2005 8:30 AM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Is there any way to enable recursive triggers? On Tue, Jan 04, 2005 at 05:54:04AM -0500, D. Richard Hipp wrote: > 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. Graeme Birchall has an excellent book (The DB2 UDB Cookbook) available for download. It has an entire chapter dedicated to DB2's Recursive SQL and one section of it is "Halting Recursive Processing". Maybe it will provide some insight. http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM enjoy, -jeremy -- Jeremy Hinegardner [EMAIL PROTECTED]
Re: [sqlite] Is there any way to enable recursive triggers?
On Tue, Jan 04, 2005 at 05:54:04AM -0500, D. Richard Hipp wrote: > 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. Graeme Birchall has an excellent book (The DB2 UDB Cookbook) available for download. It has an entire chapter dedicated to DB2's Recursive SQL and one section of it is "Halting Recursive Processing". Maybe it will provide some insight. http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM enjoy, -jeremy -- Jeremy Hinegardner [EMAIL PROTECTED]
Re: [sqlite] Is there any way to enable recursive triggers?
On 1/4/2005 at 15:54 Paolo Vernazza wrote:
>>It seems to me that recursion that never touches the same row twice
is
>>less an issue. That is a trigger that just updates all other rows in
>>the table once should be fine. So one (I suspect hard to implement)
>>idea would be to keep track of which rows have been touched as part
of
>>a trigger. Any row touched N times breaks out. This works for both
>>your delete case, and update cases.
>>
>Mmmm... let's suppose that when deleting a row in the linke list table
>we update another table incrementing a counter so we can know how many
>rows we have just deleted...
>
>CREATE TABLE list(
> id INTEGER PRIMARY KEY,
> next INTEGER REFERENCES list,
> data BLOB
> );
>
>CREATE TABLE counter (value TEXT, count INTEGER);
>INSERT INTO counter (value, count) VALUES ('deleted', 0);
>
> CREATE TRIGGER deep BEFORE DELETE ON list BEGIN
> DELETE FROM list WHERE id=old.next;
> UPDATE counter SET count=count+1 WHERE value='deleted';
> END;
>
>
>It will reveal a loop on the second trigger because we are updating
the
>same row in the table "counter"...
Good point. There is no way to solve the halting problem. No matter
what limit we set, we need some way for the user to change the limits.
In the end, limits are a convience for the programer who isn't
thinking his triggers through. (not hard in a complex database where
you are not the only one writing triggers)
I present all my ideas as special cases where we can suspect something.
We have already determined that a trigger that only deletes can never
loop forever. On Update if a row is never touched more than once, we
know there cannot be an infinite loop.
In this case we can add the special case, a trigger on DELETE can never
cause an infinite loop itself. (though of course it can hit other
triggers which could loop themselves)
I contend that we can keep adding special cases for a long time. I'm
worried that checking all the special cases can easily make sqlite one
of the slowest databases! Therefore I propose that all recursion
checking be in code that can be excluded at compile time, in addition
to run time changes to whatever limits we add. I could also see some
embedded programers who have limits in their debug builds, but release
builds are have none. (saves a a few bytes, something embedded
programers will like)
Note that it is not enough to detect out of memory situations.
Several OSes will never fail malloc (except in the case where you are
asking for memory than the hardware can address?), since they don't
give you memory until you use it. Attempt to use memory when the
system is out of it will cause your program to crash without warning!
(linux 2.2 was this way, I think 2.6 will fail malloc)
Re: [sqlite] Is there any way to enable recursive triggers?
On Jan 4, 2005, at 7:03 AM, Brass Tilde wrote: FWIW, I'm told by our DBA that SQL Server 2000 has a setting that allows or disallows recursive trigger execution. When disallowed, triggers apparently just don't recursively call themselves, even if they are designed to do so, i.e. they won't generate an error. When allowing recursion, he's not sure whether there's a limit, some internal checking that attempts to discern when reasonableness has been exceeded or if it will just merrily recurse away until stopped. And he's not willing to test it. :-) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ tsqlref/ts_create2_7eeq.asp Nested Triggers Triggers can be nested to a maximum of 32 levels. If a trigger changes a table on which there is another trigger, the second trigger is activated and can then call a third trigger, and so on. If any trigger in the chain sets off an infinite loop, the nesting level is exceeded and the trigger is canceled. To disable nested triggers, set the nested triggers option of sp_configure to 0 (off). The default configuration allows nested triggers. If nested triggers is off, recursive triggers is also disabled, regardless of the recursive triggers setting of sp_dboption. - I think Oracle has a maximum level of 50. But I have no way to test this. Seems like people have been doing OK with 0 levels of recursion, so IMHO an arbitrary stack limit which can be adjusted with a pragma would be the best/simplest solution. Trying to figure out if the user is getting into trouble using recursion would probably be a fruitless endeavor. (But, again that is just my opinion.) -Charlie
Re: [sqlite] Is there any way to enable recursive triggers?
> CREATE TRIGGER deep BEFORE DELETE ON list BEGIN > DELETE FROM list WHERE id=old.next; > END; > > This trigger is guaranteed to terminate because it will > eventually run out of entries to delete. But given any > recursion limit, we can always construct a case where > the trigger will want to run longer than the limit. > > So do we put recursion limits on UPDATE and INSERT triggers > only and let DELETE triggers run as long as they like? > That works as far as I know, but it seems kind of arbitrary. Under what circumstances might one *want* to update or insert recursively? What circumstances that can't be handled by a properly constructed query or set of queries? I can see the delete, but even that can be handled another way. I'm aware of the advantages of triggers, and the absence of stored procedures makes them even more valuable, but I'm curious. > Surely somebody else has been down this road before me and > can offer a little guidance? FWIW, I'm told by our DBA that SQL Server 2000 has a setting that allows or disallows recursive trigger execution. When disallowed, triggers apparently just don't recursively call themselves, even if they are designed to do so, i.e. they won't generate an error. When allowing recursion, he's not sure whether there's a limit, some internal checking that attempts to discern when reasonableness has been exceeded or if it will just merrily recurse away until stopped. And he's not willing to test it. :-)
Re: [sqlite] Is there any way to enable recursive triggers?
Henry Miller wrote:
It seems to me that recursion that never touches the same row twice is
less an issue. That is a trigger that just updates all other rows in
the table once should be fine. So one (I suspect hard to implement)
idea would be to keep track of which rows have been touched as part of
a trigger. Any row touched N times breaks out. This works for both
your delete case, and update cases.
Mmmm... let's suppose that when deleting a row in the linke list table
we update another table incrementing a counter so we can know how many
rows we have just deleted...
CREATE TABLE list(
id INTEGER PRIMARY KEY,
next INTEGER REFERENCES list,
data BLOB
);
CREATE TABLE counter (value TEXT, count INTEGER);
INSERT INTO counter (value, count) VALUES ('deleted', 0);
CREATE TRIGGER deep BEFORE DELETE ON list BEGIN
DELETE FROM list WHERE id=old.next;
UPDATE counter SET count=count+1 WHERE value='deleted';
END;
It will reveal a loop on the second trigger because we are updating the
same row in the table "counter"...
Paolo
Re: [sqlite] Is there any way to enable recursive triggers?
--- "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. I believe this is roughly equivalent to deadlock. It should best be dealt with in the same manner. That said, the simplest way to handle it is limiting the depth of recursion. It's simple to implement using a counter. The drawback being the user must calculate and set the depth. A more flexible option might just be to let the limit on resources handle it. Memory limits will set the upper bound on recursion. As long as you can gracefully handle and recover from that condition it should be fine. There are more complicated solutions but I personally doubt they're worth the effort. = - "Lord Tarlington gazed upon the crazed Egyptian hieroglyphics on the walls of the ancient tomb of the petrified pharaoh, he vowed there would be no curse on him like on that other Lord, unless you count his marriage to Lady Tarlington who, when the lost treasure was found, will be dumped faster than that basket in the bulrushes." Melissa Rhodes - The Castles of Dereth Calendar: a tour of the art and architecture of Asheron's Call http://www.lulu.com/content/77264 __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250
Re: [sqlite] Is there any way to enable recursive triggers?
On 1/4/2005 at 08:48 D. Richard Hipp wrote: >Peter Bartholdsson wrote: >> >> [H]ow would [limiting recursion depth] not be enough? >> > >Limiting the recursion depth would be sufficient to prevent >infinite loops. But it seems overly restrictive. > >Consider the following case: > >CREATE TABLE list( > id INTEGER PRIMARY KEY, > next INTEGER REFERENCES list, > data BLOB >); > >The table above lets you look up BLOB data given an integer >ID. It also keeps all of the entries on a linked list. >(Never mind why you would want to do this - it comes up.) >Suppose that when you delete an entry you also want to >delete all subsequent entries in the list. We have: > >CREATE TRIGGER deep BEFORE DELETE ON list BEGIN >DELETE FROM list WHERE id=old.next; >END; > >This trigger is guaranteed to terminate because it will >eventually run out of entries to delete. But given any >recursion limit, we can always construct a case where >the trigger will want to run longer than the limit. > >So do we put recursion limits on UPDATE and INSERT triggers >only and let DELETE triggers run as long as they like? >That works as far as I know, but it seems kind of arbitrary. > >Surely somebody else has been down this road before me and >can offer a little guidance? I haven't been down this road, but I have some ideas. First, we cannot solve the halting problem in the general case. All we can do is various combinations of special cases where we can solve it, and recursion limits to deal with the rest. It seems to me that recursion that never touches the same row twice is less an issue. That is a trigger that just updates all other rows in the table once should be fine. So one (I suspect hard to implement) idea would be to keep track of which rows have been touched as part of a trigger. Any row touched N times breaks out. This works for both your delete case, and update cases. It doesn't solve infinite inserts though: CREATE TRIGGER infinite BEFORE INSERT ON foo BEGIN INSERT INTO foo VALUES (...); END; With recursion limits we need some way to specify the limit as part of the SQL. Something like: CREATE TRIGGER deep BEFORE DELETE ON list BEGIN DELETE FROM list WHERE id=old.next RECURSION LIMIT SELECT COUNT FROM list; END; I don't like the above syntax, but you get the idea. This requires support for SELECT COUNT, which I believe isn't a part of sqlite. (It is a part of MSSQL) In general a recursion limit should default to infinite (put the burden on the programer to not write them, but if he must it can be set), or very low (so even a 2 row test table will hit the recursion limit and cause the programer to re-think what is happening) This all ignores what should happen if the limit is reached. There needs to be some way to specify ON CONFLICT for when recursion limits are reached.
Re: [sqlite] Is there any way to enable recursive triggers?
> So do we put recursion limits on UPDATE and INSERT triggers > only and let DELETE triggers run as long as they like? > That works as far as I know, but it seems kind of arbitrary. > > Surely somebody else has been down this road before me and > can offer a little guidance? Why don't give this burden to the user? In every language it is possible to create an infinite loop and the programmer have to fix it. Regards, Lothar
Re: [sqlite] Is there any way to enable recursive triggers?
Peter Bartholdsson wrote: [H]ow would [limiting recursion depth] not be enough? Limiting the recursion depth would be sufficient to prevent infinite loops. But it seems overly restrictive. Consider the following case: CREATE TABLE list( id INTEGER PRIMARY KEY, next INTEGER REFERENCES list, data BLOB ); The table above lets you look up BLOB data given an integer ID. It also keeps all of the entries on a linked list. (Never mind why you would want to do this - it comes up.) Suppose that when you delete an entry you also want to delete all subsequent entries in the list. We have: CREATE TRIGGER deep BEFORE DELETE ON list BEGIN DELETE FROM list WHERE id=old.next; END; This trigger is guaranteed to terminate because it will eventually run out of entries to delete. But given any recursion limit, we can always construct a case where the trigger will want to run longer than the limit. So do we put recursion limits on UPDATE and INSERT triggers only and let DELETE triggers run as long as they like? That works as far as I know, but it seems kind of arbitrary. Surely somebody else has been down this road before me and can offer a little guidance? -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
Re: [sqlite] Is there any way to enable recursive triggers?
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
Re: [sqlite] Is there any way to enable recursive triggers?
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. Cláudio > 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. > > Example: How should SQLite deal with this: > > CREATE TABLE ex1(a INTEGER); > INSERT INTO ex1 VALUES(1); > CREATE TRIGGER tr1 AFTER UPDATE ON ex1 BEGIN > UPDATE ex1 SET a=a+1 WHERE rowid=old.rowid; > END; > > UPDATE ex1 SET a=2 WHERE a=1; -- infinite loop > here > > > -- > D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 > > = = Sabedoria: "O FRACO PERECERÁ." Sugestão : CAI [www.cai.org.br] = ___ Yahoo! Acesso Grátis - Instale o discador do Yahoo! agora. http://br.acesso.yahoo.com/ - Internet rápida e grátis
Re: [sqlite] Is there any way to enable recursive triggers?
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. Example: How should SQLite deal with this: CREATE TABLE ex1(a INTEGER); INSERT INTO ex1 VALUES(1); CREATE TRIGGER tr1 AFTER UPDATE ON ex1 BEGIN UPDATE ex1 SET a=a+1 WHERE rowid=old.rowid; END; UPDATE ex1 SET a=2 WHERE a=1; -- infinite loop here -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
[sqlite] Is there any way to enable recursive triggers?
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. Regards, Peter Bartholdsson
