On Tue, 1 Sep 2009 09:51:39 +0200, Alejandro Ruiz-Oriol
<aruiz...@itelsys.com> wrote:
>Yes, but how do I know in the PHP fired by the trigger what's the PHP
>context of his "parent"?.
>
>Let me explain it.
>
>Inside the trigger I excute something like
>
>select test();
>
>where test is a registered php function.
>
>When the trigger fires, the php function gets called, but the first thing I
>need to have is a database handler. Right know, the first thing I do in
>that test php is:
>
>$dbh = new PDO('sqlite:mydb.sqlite');
>
>so that creates a new (an different) context, then if I try to:
>
>$res=$dbh->query("update set field=1 from same_table_that fired_the
>trigger");
>
>I run in a deadlock, the first trigger is locking the table, and I'm waiting
>for that trigger to relese the lock. This will only end by time-out with the
>error "Database locked".
>
>so, how can the php fired by a trigger knows whats the php sqlite context of
>its caller??
You have a php script. It opens a database handle and
registers a function. Then it executes some SQL code which
fires a trigger, which in his turn calls your registered
function.
All these nested calls execute in the same context, not
asynchronically. So the database handle you opened in the
top level is still valid when your registered function is
called. In other words, you don't have to open a second
handle.
Opening a second handle and starting a transaction causes
the lock.
How the function gets the handle is another matter.
If $dbh is a global variable you could simply use that.
All in all, it is quite complicated, probably too
complicated. Are you sure your registered function really
needs to use the database handle?
Can't you just use SQL in the trigger, and restrict the
function to what functions are useful for, like calculations
which can't be donein SQL or aggregation tasks?
--
( Kees Nuyt
)
c[_]
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
