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??
thx again
2009/8/31 Kees Nuyt <[email protected]>
> On Mon, 31 Aug 2009 11:58:42 +0200, Alejandro Ruiz-Oriol
> <[email protected]> wrote:
>
> >I've been doing some further reading and I think that I already have the
> >answer and it's "No, no way to avoid this".
> >
> >As far as I've read, when you start any update function, SQLite makes an
> >exclusive write lock to the table. As far as I'm excuting from inside an
> >update trigger, the database is "exclusivily write locked", so if that
> >trigger tries to write to the DB, we will end up in a deadlock.
> >
> >The only thing that can "save" me from this behavior is if there is
> someway
> >to tell SQLite that the update is over, before the trigger finished.
> >
> >I've tried to put a commit inside the trigger, but I get a "syntax error".
> >
> >I'm working in to aporaches to the workarund. One i ssplit the table in
> two
> >(due to the logic of my aplication, maybe I can do this, cause the files
> >updated by the trigger can have some kind of logic that I can use to split
> >the table in 2 different tables). The other is to start a background php
> >task that wait till the DB lock is released and then, tries the insert.
> >
> >Any suggestion?
>
> I think the registered callback function runs in the same
> context as the php script that created the first conection,
> and it should use that conenction, instead of creating a
> second connection.
> It's just a suggestion. I didn't try this myself.
> --
> ( Kees Nuyt
> )
> c[_]
> _______________________________________________
> sqlite-users mailing list
> [email protected]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
