getting transactions to work
getting transactions to work
am 30.07.2004 16:53:01 von zedaardv
there seems to be very little info around on actually using
transactions with postgres. i've tried to create a page that will take
input from a form and insert it into my database. it works if i just
do it without transactions but when i try to use with the begin and
commit sections of code, it doesn't update the data base. i'm guessing
it is doing a rollback when my page loads itself again. can anyone
help me out here ?
thanks
r
code below
those eyes
$conn = pg_connect("dbname=entish user=postgres");
if(!$conn)
{
print "not for the chocolate";
exit;
}
if ($_POST[submit]) {
$begin = pg_query("begin");
$isql = "insert into diety(diety,culture,gender)
values
('$_POST[diety]','$_POST[culture]','$_POST[gender]')";
printf("-- %s --\n",$isql);
$results = pg_query($isql);
?>
}
else if(!$_POST[action]) {
?>
}
else {
if($_POST[action] == 'commit') {
echo "let me see";
$act = pg_query("commit");
}
else {
$act = pg_query("rollback");
}
} //end if $_POST[submit]
?>
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
Re: [0.2] getting transactions to work
am 30.07.2004 16:57:47 von Rod Kreisler
You are correct. You cannot have a transaction span multiple pages/scripts.
reiner peterke wrote:
> there seems to be very little info around on actually using
> transactions with postgres. i've tried to create a page that will
> take input from a form and insert it into my database. it works if i
> just do it without transactions but when i try to use with the begin
> and commit sections of code, it doesn't update the data base. i'm
> guessing it is doing a rollback when my page loads itself again. can
> anyone help me out here ?
>
> thanks
>
> r
>
> code below
>
>
>
> those eyes
>
>
>
> $conn = pg_connect("dbname=entish user=postgres");
> if(!$conn)
> {
> print "not for the chocolate";
> exit;
> }
> if ($_POST[submit]) {
>
> $begin = pg_query("begin");
> $isql = "insert into diety(diety,culture,gender)
> values
> ('$_POST[diety]','$_POST[culture]','$_POST[gender]')";
> printf("-- %s --\n",$isql);
> $results = pg_query($isql);
> ?>
>
>
> }
> else if(!$_POST[action]) {
> ?>
>
>
> }
> else {
> if($_POST[action] == 'commit') {
> echo "let me see";
> $act = pg_query("commit");
> }
> else {
> $act = pg_query("rollback");
> }
> } //end if $_POST[submit]
> ?>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Re: [0.2] getting transactions to work
am 30.07.2004 17:03:49 von zedaardv
this is meant in all honesty,
then whats the point?!
ok, let me put it this way. is there no way to implement pages using
transactions?
otherwise it seems to kind of defeat the purpose of them.
r
On 30 jul 2004, at 16.57, Rod K wrote:
> You are correct. You cannot have a transaction span multiple
> pages/scripts.
>
> reiner peterke wrote:
>
>> there seems to be very little info around on actually using
>> transactions with postgres. i've tried to create a page that will
>> take input from a form and insert it into my database. it works if i
>> just do it without transactions but when i try to use with the begin
>> and commit sections of code, it doesn't update the data base. i'm
>> guessing it is doing a rollback when my page loads itself again. can
>> anyone help me out here ?
>>
>> thanks
>>
>> r
>>
>> code below
>>
>>
>>
>> those eyes
>>
>>
>>
>> $conn = pg_connect("dbname=entish user=postgres");
>> if(!$conn)
>> {
>> print "not for the chocolate";
>> exit;
>> }
>> if ($_POST[submit]) {
>>
>> $begin = pg_query("begin");
>> $isql = "insert into diety(diety,culture,gender)
>> values
>> ('$_POST[diety]','$_POST[culture]','$_POST[gender]')";
>> printf("-- %s --\n",$isql);
>> $results = pg_query($isql);
>> ?>
>>
>>
>> }
>> else if(!$_POST[action]) {
>> ?>
>>
>>
>> }
>> else {
>> if($_POST[action] == 'commit') {
>> echo "let me see";
>> $act = pg_query("commit");
>> }
>> else {
>> $act = pg_query("rollback");
>> }
>> } //end if $_POST[submit]
>> ?>
>>
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 8: explain analyze is your friend
>
>
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Re: [0.0] Re: [0.2] getting transactions to work
am 30.07.2004 17:11:35 von Rod Kreisler
You can find many resources to explain their purpose better than I can
do here.
To be honest, I can't see what you are trying to accomplish in your
script. If it's validation you should be using session variables to
store the input AND echoing what was inputed on the validation page.
reiner peterke wrote:
> this is meant in all honesty,
>
> then whats the point?!
>
> ok, let me put it this way. is there no way to implement pages using
> transactions?
> otherwise it seems to kind of defeat the purpose of them.
>
> r
> On 30 jul 2004, at 16.57, Rod K wrote:
>
>> You are correct. You cannot have a transaction span multiple
>> pages/scripts.
>>
>> reiner peterke wrote:
>>
>>> there seems to be very little info around on actually using
>>> transactions with postgres. i've tried to create a page that will
>>> take input from a form and insert it into my database. it works if
>>> i just do it without transactions but when i try to use with the
>>> begin and commit sections of code, it doesn't update the data base.
>>> i'm guessing it is doing a rollback when my page loads itself
>>> again. can anyone help me out here ?
>>>
>>> thanks
>>>
>>> r
>>>
>>> code below
>>>
>>>
>>>
>>> those eyes
>>>
>>>
>>>
>>> $conn = pg_connect("dbname=entish user=postgres");
>>> if(!$conn)
>>> {
>>> print "not for the chocolate";
>>> exit;
>>> }
>>> if ($_POST[submit]) {
>>>
>>> $begin = pg_query("begin");
>>> $isql = "insert into diety(diety,culture,gender)
>>> values
>>> ('$_POST[diety]','$_POST[culture]','$_POST[gender]')";
>>> printf("-- %s --\n",$isql);
>>> $results = pg_query($isql);
>>> ?>
>>>
>>>
>>> }
>>> else if(!$_POST[action]) {
>>> ?>
>>>
>>>
>>> }
>>> else {
>>> if($_POST[action] == 'commit') {
>>> echo "let me see";
>>> $act = pg_query("commit");
>>> }
>>> else {
>>> $act = pg_query("rollback");
>>> }
>>> } //end if $_POST[submit]
>>> ?>
>>>
>>>
>>> ---------------------------(end of
>>> broadcast)---------------------------
>>> TIP 8: explain analyze is your friend
>>
>>
>>
>
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [0.2] getting transactions to work
am 30.07.2004 17:21:14 von bruce
if psgres works as mysql.... you should be able to do it...
but the issue appears to be that the connection you establish with the db in
one page, is not available once you shut the page down.
within mysql, there appears to be a mysqli group of functions that are setup
to accommodate transactions across multiple pages... i would imagine/hope
that the same sort of functionality is available for posgres....
i'm getting close to needing the same functionality with mysql, and i'm
betting/hoping like hell that what i've just described is how mysql/php
works...
-bruce
-----Original Message-----
From: pgsql-php-owner@postgresql.org
[mailto:pgsql-php-owner@postgresql.org]On Behalf Of reiner peterke
Sent: Friday, July 30, 2004 8:04 AM
To: Rod K
Cc: pgsql-php@postgresql.org
Subject: Re: [0.2] [PHP] getting transactions to work
this is meant in all honesty,
then whats the point?!
ok, let me put it this way. is there no way to implement pages using
transactions?
otherwise it seems to kind of defeat the purpose of them.
r
On 30 jul 2004, at 16.57, Rod K wrote:
> You are correct. You cannot have a transaction span multiple
> pages/scripts.
>
> reiner peterke wrote:
>
>> there seems to be very little info around on actually using
>> transactions with postgres. i've tried to create a page that will
>> take input from a form and insert it into my database. it works if i
>> just do it without transactions but when i try to use with the begin
>> and commit sections of code, it doesn't update the data base. i'm
>> guessing it is doing a rollback when my page loads itself again. can
>> anyone help me out here ?
>>
>> thanks
>>
>> r
>>
>> code below
>>
>>
>>
>> those eyes
>>
>>
>>
>> $conn = pg_connect("dbname=entish user=postgres");
>> if(!$conn)
>> {
>> print "not for the chocolate";
>> exit;
>> }
>> if ($_POST[submit]) {
>>
>> $begin = pg_query("begin");
>> $isql = "insert into diety(diety,culture,gender)
>> values
>> ('$_POST[diety]','$_POST[culture]','$_POST[gender]')";
>> printf("-- %s --\n",$isql);
>> $results = pg_query($isql);
>> ?>
>>
>>
>> }
>> else if(!$_POST[action]) {
>> ?>
>>
>>
>> }
>> else {
>> if($_POST[action] == 'commit') {
>> echo "let me see";
>> $act = pg_query("commit");
>> }
>> else {
>> $act = pg_query("rollback");
>> }
>> } //end if $_POST[submit]
>> ?>
>>
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 8: explain analyze is your friend
>
>
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [0.0] Re: [0.2] getting transactions to work
am 30.07.2004 18:05:06 von zedaardv
i'm trying to test an idea. i know what i sent doesn't do much, but i
try out ideas before i go too far to make sure i understand what i
think i do
in my 'real life' i work with oracle. i like the idea of explicitly
telling the database when i'm done. i want to be able to trap errors
and rollback if necessary. also to give someone the choice of saving
the work or not. i know there are things i can do to create the
similar effect,
create the sql, then when i'm ready submit it to the database.
i guess i'm trying to test the limits right now!
thanks for the input.
r
On 30 jul 2004, at 17.11, Rod K wrote:
> You can find many resources to explain their purpose better than I can
> do here.
>
> To be honest, I can't see what you are trying to accomplish in your
> script. If it's validation you should be using session variables to
> store the input AND echoing what was inputed on the validation page.
>
> reiner peterke wrote:
>
>> this is meant in all honesty,
>>
>> then whats the point?!
>>
>> ok, let me put it this way. is there no way to implement pages using
>> transactions?
>> otherwise it seems to kind of defeat the purpose of them.
>>
>> r
>> On 30 jul 2004, at 16.57, Rod K wrote:
>>
>>> You are correct. You cannot have a transaction span multiple
>>> pages/scripts.
>>>
>>> reiner peterke wrote:
>>>
>>>> there seems to be very little info around on actually using
>>>> transactions with postgres. i've tried to create a page that will
>>>> take input from a form and insert it into my database. it works if
>>>> i just do it without transactions but when i try to use with the
>>>> begin and commit sections of code, it doesn't update the data base.
>>>> i'm guessing it is doing a rollback when my page loads itself
>>>> again. can anyone help me out here ?
>>>>
>>>> thanks
>>>>
>>>> r
>>>>
>>>> code below
>>>>
>>>>
>>>>
>>>> those eyes
>>>>
>>>>
>>>>
>>>> $conn = pg_connect("dbname=entish user=postgres");
>>>> if(!$conn)
>>>> {
>>>> print "not for the chocolate";
>>>> exit;
>>>> }
>>>> if ($_POST[submit]) {
>>>>
>>>> $begin = pg_query("begin");
>>>> $isql = "insert into diety(diety,culture,gender)
>>>> values
>>>> ('$_POST[diety]','$_POST[culture]','$_POST[gender]')";
>>>> printf("-- %s --\n",$isql);
>>>> $results = pg_query($isql);
>>>> ?>
>>>>
>>>>
>>>> }
>>>> else if(!$_POST[action]) {
>>>> ?>
>>>>
>>>>
>>>> }
>>>> else {
>>>> if($_POST[action] == 'commit') {
>>>> echo "let me see";
>>>> $act = pg_query("commit");
>>>> }
>>>> else {
>>>> $act = pg_query("rollback");
>>>> }
>>>> } //end if $_POST[submit]
>>>> ?>
>>>>
>>>>
>>>> ---------------------------(end of
>>>> broadcast)---------------------------
>>>> TIP 8: explain analyze is your friend
>>>
>>>
>>>
>>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
Re: [0.2] getting transactions to work
am 30.07.2004 18:08:25 von zedaardv
well i've read about this thing called persistent connection,
i think it is supposed to exist in mysql also. the idea sound like
what i want. i've tried it but i didn't get any different results. but
then i'm not convinced i did it right either.
r
On 30 jul 2004, at 17.21, bruce wrote:
> if psgres works as mysql.... you should be able to do it...
>
> but the issue appears to be that the connection you establish with the
> db in
> one page, is not available once you shut the page down.
>
> within mysql, there appears to be a mysqli group of functions that are
> setup
> to accommodate transactions across multiple pages... i would
> imagine/hope
> that the same sort of functionality is available for posgres....
>
> i'm getting close to needing the same functionality with mysql, and i'm
> betting/hoping like hell that what i've just described is how mysql/php
> works...
>
> -bruce
>
>
> -----Original Message-----
> From: pgsql-php-owner@postgresql.org
> [mailto:pgsql-php-owner@postgresql.org]On Behalf Of reiner peterke
> Sent: Friday, July 30, 2004 8:04 AM
> To: Rod K
> Cc: pgsql-php@postgresql.org
> Subject: Re: [0.2] [PHP] getting transactions to work
>
>
> this is meant in all honesty,
>
> then whats the point?!
>
> ok, let me put it this way. is there no way to implement pages using
> transactions?
> otherwise it seems to kind of defeat the purpose of them.
>
> r
> On 30 jul 2004, at 16.57, Rod K wrote:
>
>> You are correct. You cannot have a transaction span multiple
>> pages/scripts.
>>
>> reiner peterke wrote:
>>
>>> there seems to be very little info around on actually using
>>> transactions with postgres. i've tried to create a page that will
>>> take input from a form and insert it into my database. it works if i
>>> just do it without transactions but when i try to use with the begin
>>> and commit sections of code, it doesn't update the data base. i'm
>>> guessing it is doing a rollback when my page loads itself again. can
>>> anyone help me out here ?
>>>
>>> thanks
>>>
>>> r
>>>
>>> code below
>>>
>>>
>>>
>>> those eyes
>>>
>>>
>>>
>>> $conn = pg_connect("dbname=entish user=postgres");
>>> if(!$conn)
>>> {
>>> print "not for the chocolate";
>>> exit;
>>> }
>>> if ($_POST[submit]) {
>>>
>>> $begin = pg_query("begin");
>>> $isql = "insert into diety(diety,culture,gender)
>>> values
>>> ('$_POST[diety]','$_POST[culture]','$_POST[gender]')";
>>> printf("-- %s --\n",$isql);
>>> $results = pg_query($isql);
>>> ?>
>>>
>>>
>>> }
>>> else if(!$_POST[action]) {
>>> ?>
>>>
>>>
>>> }
>>> else {
>>> if($_POST[action] == 'commit') {
>>> echo "let me see";
>>> $act = pg_query("commit");
>>> }
>>> else {
>>> $act = pg_query("rollback");
>>> }
>>> } //end if $_POST[submit]
>>> ?>
>>>
>>>
>>> ---------------------------(end of
>>> broadcast)---------------------------
>>> TIP 8: explain analyze is your friend
>>
>>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if
> your
> joining column's datatypes do not match
>
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
Re: [0.0] Re: [0.2] getting transactions to work
am 30.07.2004 18:13:35 von Rod Kreisler
No, persistent connections will not work either.
reiner peterke wrote:
> well i've read about this thing called persistent connection,
> i think it is supposed to exist in mysql also. the idea sound like
> what i want. i've tried it but i didn't get any different results.
> but then i'm not convinced i did it right either.
>
> r
>
> On 30 jul 2004, at 17.21, bruce wrote:
>
>> if psgres works as mysql.... you should be able to do it...
>>
>> but the issue appears to be that the connection you establish with
>> the db in
>> one page, is not available once you shut the page down.
>>
>> within mysql, there appears to be a mysqli group of functions that
>> are setup
>> to accommodate transactions across multiple pages... i would
>> imagine/hope
>> that the same sort of functionality is available for posgres....
>>
>> i'm getting close to needing the same functionality with mysql, and i'm
>> betting/hoping like hell that what i've just described is how mysql/php
>> works...
>>
>> -bruce
>>
>>
>> -----Original Message-----
>> From: pgsql-php-owner@postgresql.org
>> [mailto:pgsql-php-owner@postgresql.org]On Behalf Of reiner peterke
>> Sent: Friday, July 30, 2004 8:04 AM
>> To: Rod K
>> Cc: pgsql-php@postgresql.org
>> Subject: Re: [0.2] [PHP] getting transactions to work
>>
>>
>> this is meant in all honesty,
>>
>> then whats the point?!
>>
>> ok, let me put it this way. is there no way to implement pages using
>> transactions?
>> otherwise it seems to kind of defeat the purpose of them.
>>
>> r
>> On 30 jul 2004, at 16.57, Rod K wrote:
>>
>>> You are correct. You cannot have a transaction span multiple
>>> pages/scripts.
>>>
>>> reiner peterke wrote:
>>>
>>>> there seems to be very little info around on actually using
>>>> transactions with postgres. i've tried to create a page that will
>>>> take input from a form and insert it into my database. it works if i
>>>> just do it without transactions but when i try to use with the begin
>>>> and commit sections of code, it doesn't update the data base. i'm
>>>> guessing it is doing a rollback when my page loads itself again. can
>>>> anyone help me out here ?
>>>>
>>>> thanks
>>>>
>>>> r
>>>>
>>>> code below
>>>>
>>>>
>>>>
>>>> those eyes
>>>>
>>>>
>>>>
>>>> $conn = pg_connect("dbname=entish user=postgres");
>>>> if(!$conn)
>>>> {
>>>> print "not for the chocolate";
>>>> exit;
>>>> }
>>>> if ($_POST[submit]) {
>>>>
>>>> $begin = pg_query("begin");
>>>> $isql = "insert into diety(diety,culture,gender)
>>>> values
>>>> ('$_POST[diety]','$_POST[culture]','$_POST[gender]')";
>>>> printf("-- %s --\n",$isql);
>>>> $results = pg_query($isql);
>>>> ?>
>>>>
>>>>
>>>> }
>>>> else if(!$_POST[action]) {
>>>> ?>
>>>>
>>>>
>>>> }
>>>> else {
>>>> if($_POST[action] == 'commit') {
>>>> echo "let me see";
>>>> $act = pg_query("commit");
>>>> }
>>>> else {
>>>> $act = pg_query("rollback");
>>>> }
>>>> } //end if $_POST[submit]
>>>> ?>
>>>>
>>>>
>>>> ---------------------------(end of
>>>> broadcast)---------------------------
>>>> TIP 8: explain analyze is your friend
>>>
>>>
>>>
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 7: don't forget to increase your free space map settings
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 9: the planner will ignore your desire to choose an index scan if
>> your
>> joining column's datatypes do not match
>>
>
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [0.0] Re: [0.2] getting transactions to work
am 30.07.2004 18:26:40 von zedaardv
ok,
thanks
On 30 jul 2004, at 18.13, Rod K wrote:
> No, persistent connections will not work either.
>
> reiner peterke wrote:
>
>> well i've read about this thing called persistent connection,
>> i think it is supposed to exist in mysql also. the idea sound like
>> what i want. i've tried it but i didn't get any different results.
>> but then i'm not convinced i did it right either.
>>
>> r
>>
>> On 30 jul 2004, at 17.21, bruce wrote:
>>
>>> if psgres works as mysql.... you should be able to do it...
>>>
>>> but the issue appears to be that the connection you establish with
>>> the db in
>>> one page, is not available once you shut the page down.
>>>
>>> within mysql, there appears to be a mysqli group of functions that
>>> are setup
>>> to accommodate transactions across multiple pages... i would
>>> imagine/hope
>>> that the same sort of functionality is available for posgres....
>>>
>>> i'm getting close to needing the same functionality with mysql, and
>>> i'm
>>> betting/hoping like hell that what i've just described is how
>>> mysql/php
>>> works...
>>>
>>> -bruce
>>>
>>>
>>> -----Original Message-----
>>> From: pgsql-php-owner@postgresql.org
>>> [mailto:pgsql-php-owner@postgresql.org]On Behalf Of reiner peterke
>>> Sent: Friday, July 30, 2004 8:04 AM
>>> To: Rod K
>>> Cc: pgsql-php@postgresql.org
>>> Subject: Re: [0.2] [PHP] getting transactions to work
>>>
>>>
>>> this is meant in all honesty,
>>>
>>> then whats the point?!
>>>
>>> ok, let me put it this way. is there no way to implement pages using
>>> transactions?
>>> otherwise it seems to kind of defeat the purpose of them.
>>>
>>> r
>>> On 30 jul 2004, at 16.57, Rod K wrote:
>>>
>>>> You are correct. You cannot have a transaction span multiple
>>>> pages/scripts.
>>>>
>>>> reiner peterke wrote:
>>>>
>>>>> there seems to be very little info around on actually using
>>>>> transactions with postgres. i've tried to create a page that will
>>>>> take input from a form and insert it into my database. it works
>>>>> if i
>>>>> just do it without transactions but when i try to use with the
>>>>> begin
>>>>> and commit sections of code, it doesn't update the data base. i'm
>>>>> guessing it is doing a rollback when my page loads itself again.
>>>>> can
>>>>> anyone help me out here ?
>>>>>
>>>>> thanks
>>>>>
>>>>> r
>>>>>
>>>>> code below
>>>>>
>>>>>
>>>>>
>>>>> those eyes
>>>>>
>>>>>
>>>>>
>>>>> $conn = pg_connect("dbname=entish user=postgres");
>>>>> if(!$conn)
>>>>> {
>>>>> print "not for the chocolate";
>>>>> exit;
>>>>> }
>>>>> if ($_POST[submit]) {
>>>>>
>>>>> $begin = pg_query("begin");
>>>>> $isql = "insert into diety(diety,culture,gender)
>>>>> values
>>>>> ('$_POST[diety]','$_POST[culture]','$_POST[gender]')";
>>>>> printf("-- %s --\n",$isql);
>>>>> $results = pg_query($isql);
>>>>> ?>
>>>>>
>>>>>
>>>>> }
>>>>> else if(!$_POST[action]) {
>>>>> ?>
>>>>>
>>>>>
>>>>> }
>>>>> else {
>>>>> if($_POST[action] == 'commit') {
>>>>> echo "let me see";
>>>>> $act = pg_query("commit");
>>>>> }
>>>>> else {
>>>>> $act = pg_query("rollback");
>>>>> }
>>>>> } //end if $_POST[submit]
>>>>> ?>
>>>>>
>>>>>
>>>>> ---------------------------(end of
>>>>> broadcast)---------------------------
>>>>> TIP 8: explain analyze is your friend
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------(end of
>>> broadcast)---------------------------
>>> TIP 7: don't forget to increase your free space map settings
>>>
>>>
>>> ---------------------------(end of
>>> broadcast)---------------------------
>>> TIP 9: the planner will ignore your desire to choose an index scan
>>> if your
>>> joining column's datatypes do not match
>>>
>>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Re: [0.2] getting transactions to work
am 30.07.2004 18:31:30 von Christopher Kings-Lynne
> i'm getting close to needing the same functionality with mysql, and i'm
> betting/hoping like hell that what i've just described is how mysql/php
> works...
Err, it's not.
Chris
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Re: [0.0] Re: [0.2] getting transactions to work
am 30.07.2004 18:32:45 von Christopher Kings-Lynne
> i'm trying to test an idea. i know what i sent doesn't do much, but i
> try out ideas before i go too far to make sure i understand what i think
> i do
> in my 'real life' i work with oracle. i like the idea of explicitly
> telling the database when i'm done. i want to be able to trap errors
> and rollback if necessary. also to give someone the choice of saving
> the work or not. i know there are things i can do to create the similar
> effect,
> create the sql, then when i'm ready submit it to the database.
Oracle doesn't do what you want either. I'm afraid you have a
fundamental misunderstanding of how the HTTP process works.
Chris
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
Re: [0.0] Re: [0.2] getting transactions to work
am 30.07.2004 18:35:14 von bruce
the idea behind persistent connections is to simply allow you to open a
connection, that is persistent, ie, it's there for other db functions to use
and that the app doesn't go through the process of opening up a new
connection. with a persistent connection, the app essentially looks to see
if an existing connection has already been open that's available for use.
-bruce
-----Original Message-----
From: reiner peterke [mailto:zedaardv@drizzle.com]
Sent: Friday, July 30, 2004 9:27 AM
To: Rod K
Cc: pgsql-php@postgresql.org; bedouglas@earthlink.net
Subject: Re: [0.0] Re: [0.2] [PHP] getting transactions to work
ok,
thanks
On 30 jul 2004, at 18.13, Rod K wrote:
> No, persistent connections will not work either.
>
> reiner peterke wrote:
>
>> well i've read about this thing called persistent connection,
>> i think it is supposed to exist in mysql also. the idea sound like
>> what i want. i've tried it but i didn't get any different results.
>> but then i'm not convinced i did it right either.
>>
>> r
>>
>> On 30 jul 2004, at 17.21, bruce wrote:
>>
>>> if psgres works as mysql.... you should be able to do it...
>>>
>>> but the issue appears to be that the connection you establish with
>>> the db in
>>> one page, is not available once you shut the page down.
>>>
>>> within mysql, there appears to be a mysqli group of functions that
>>> are setup
>>> to accommodate transactions across multiple pages... i would
>>> imagine/hope
>>> that the same sort of functionality is available for posgres....
>>>
>>> i'm getting close to needing the same functionality with mysql, and
>>> i'm
>>> betting/hoping like hell that what i've just described is how
>>> mysql/php
>>> works...
>>>
>>> -bruce
>>>
>>>
>>> -----Original Message-----
>>> From: pgsql-php-owner@postgresql.org
>>> [mailto:pgsql-php-owner@postgresql.org]On Behalf Of reiner peterke
>>> Sent: Friday, July 30, 2004 8:04 AM
>>> To: Rod K
>>> Cc: pgsql-php@postgresql.org
>>> Subject: Re: [0.2] [PHP] getting transactions to work
>>>
>>>
>>> this is meant in all honesty,
>>>
>>> then whats the point?!
>>>
>>> ok, let me put it this way. is there no way to implement pages using
>>> transactions?
>>> otherwise it seems to kind of defeat the purpose of them.
>>>
>>> r
>>> On 30 jul 2004, at 16.57, Rod K wrote:
>>>
>>>> You are correct. You cannot have a transaction span multiple
>>>> pages/scripts.
>>>>
>>>> reiner peterke wrote:
>>>>
>>>>> there seems to be very little info around on actually using
>>>>> transactions with postgres. i've tried to create a page that will
>>>>> take input from a form and insert it into my database. it works
>>>>> if i
>>>>> just do it without transactions but when i try to use with the
>>>>> begin
>>>>> and commit sections of code, it doesn't update the data base. i'm
>>>>> guessing it is doing a rollback when my page loads itself again.
>>>>> can
>>>>> anyone help me out here ?
>>>>>
>>>>> thanks
>>>>>
>>>>> r
>>>>>
>>>>> code below
>>>>>
>>>>>
>>>>>
>>>>> those eyes
>>>>>
>>>>>
>>>>>
>>>>> $conn = pg_connect("dbname=entish user=postgres");
>>>>> if(!$conn)
>>>>> {
>>>>> print "not for the chocolate";
>>>>> exit;
>>>>> }
>>>>> if ($_POST[submit]) {
>>>>>
>>>>> $begin = pg_query("begin");
>>>>> $isql = "insert into diety(diety,culture,gender)
>>>>> values
>>>>> ('$_POST[diety]','$_POST[culture]','$_POST[gender]')";
>>>>> printf("-- %s --\n",$isql);
>>>>> $results = pg_query($isql);
>>>>> ?>
>>>>>
>>>>>
>>>>> }
>>>>> else if(!$_POST[action]) {
>>>>> ?>
>>>>>
>>>>>
>>>>> }
>>>>> else {
>>>>> if($_POST[action] == 'commit') {
>>>>> echo "let me see";
>>>>> $act = pg_query("commit");
>>>>> }
>>>>> else {
>>>>> $act = pg_query("rollback");
>>>>> }
>>>>> } //end if $_POST[submit]
>>>>> ?>
>>>>>
>>>>>
>>>>> ---------------------------(end of
>>>>> broadcast)---------------------------
>>>>> TIP 8: explain analyze is your friend
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------(end of
>>> broadcast)---------------------------
>>> TIP 7: don't forget to increase your free space map settings
>>>
>>>
>>> ---------------------------(end of
>>> broadcast)---------------------------
>>> TIP 9: the planner will ignore your desire to choose an index scan
>>> if your
>>> joining column's datatypes do not match
>>>
>>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
Re: [0.0] Re: [0.2] getting transactions to work
am 30.07.2004 18:57:53 von zedaardv
i never said oracle did do that.
i don 't have so much experience working with databases and web pages
i do not have any understanding or misunderstanding. i am trying to
learn how it does work here. to my mind it should be able to work
within a web page. maybe you could be so kind as to explain to me why
it does not work.
r
On 30 jul 2004, at 18.32, Christopher Kings-Lynne wrote:
>> i'm trying to test an idea. i know what i sent doesn't do much, but
>> i try out ideas before i go too far to make sure i understand what i
>> think i do
>> in my 'real life' i work with oracle. i like the idea of explicitly
>> telling the database when i'm done. i want to be able to trap errors
>> and rollback if necessary. also to give someone the choice of saving
>> the work or not. i know there are things i can do to create the
>> similar effect,
>> create the sql, then when i'm ready submit it to the database.
>
> Oracle doesn't do what you want either. I'm afraid you have a
> fundamental misunderstanding of how the HTTP process works.
>
> Chris
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
> majordomo@postgresql.org
>
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [0.0] Re: [0.2] getting transactions to work
am 30.07.2004 20:48:40 von Thom Dyson
Under PHP (or any cgi type of process), postgres sessions cannot cross
multiple html pages. This is neither a flaw in PHP nor postgres; it is a
fact that is database and language independent.
Each page submission, that is each php invocation, starts a session that is
closed when the php script is done. the stateless nature of HTTP is at the
heart of this. A web server sees each page request as a stand alone event,
with no relationship to any other request. The ability to do "sessions" is
the work around to this.
So, if you need to carry information from one web page to another , you
either have to write hidden values to the html page (a bad idea on sorts of
levels) or use session variables to that PHP/postgres can retain
information.
Thom Dyson
Director of Information Services
Sybex, Inc.
pgsql-php-owner@postgresql.org wrote on 07/30/2004 09:57:53 AM:
> i never said oracle did do that.
> i don 't have so much experience working with databases and web pages
> i do not have any understanding or misunderstanding. i am trying to
> learn how it does work here. to my mind it should be able to work
> within a web page. maybe you could be so kind as to explain to me why
> it does not work.
> r
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
Re: [0.2] getting transactions to work
am 30.07.2004 21:54:36 von Frank Finner
WW91IGNvdWxkIGhhdmUgYSB0cmFuc2FjdGlvbiBzcGFuIG11bHRpcGxlIHBh
Z2VzIChub3Qgc2NyaXB0cyksIGlmIHlvdSBrZWVwIHRoZQ0Kc2NyaXB0IGlu
IG1lbW9yeSBhbmQgdXNlIGRpZmZlcmVudCBwYXJ0cyBvZiBpdCB3aXRoIGRp
ZmZlcmVudCB0ZW1wbGF0ZXMgZm9yDQpkaWZmZXJlbnQgcGFnZXMuIFRoaXMg
aXMgcG9zc2libGUgdXNpbmcgRmFzdENHSSAoaHR0cDovL3d3dy5mYXN0Y2dp
LmNvbSkuIEkNCmRvIHRoaXMgd2l0aCBQZXJsLCBvY2Nhc2lvbmFsbHkgd2l0
aCBDLCBidXQgSSBkaWQgbm90IGhhdmUgc3BhcmUgdGltZSB0byB0cnkgaXQN
CndpdGggUEhQLCBhbHRob3VnaCBpdCBzaG91bGQgd29yaywgaWYgeW91IHVz
ZSBQSFAgbGlrZSBhIEZhc3RDR0kgQ0dJIHNjcmlwdCwgYW5kDQpub3QgYSBv
bmUtc2NyaXB0LXBlci1wYWdlIHRlY2huaXF1ZS4NCg0KT2YgY291cnNlIHRo
ZXJlIGFyZSBzb21lIGRyYXdiYWNrcyBsaWtlIG5lY2Vzc2l0eSB0byBhbHdh
eXMgaW5pdGlhbGlzZQ0KdmFyaWFibGVzIHZlcnkgY2FyZWZ1bGx5LCBwb3Nz
aWJpbGl0eSBvZiBub3RpY2VhYmxlIG1lbW9yeSBsZWFrcyBhbmQgc3RyYW5n
ZQ0KY2FjaGVpbmcgZWZmZWN0cy4gSW4gZmFjdCB3aXRoIEZhc3RDR0kgeW91
IGNyZWF0ZSBhIHBlcnNpc3RlbnQgc2VydmVyDQphcHBsaWNhdGlvbiBjb25u
ZWN0ZWQgdG8geW91ciB3ZWJzZXJ2ZXIsIG5vdCBqdXN0IGEgdm9sYXRpbGUg
c2NyaXB0Lg0KDQpSZWdhcmRzLCBGcmFuay4NCg0KDQpPbiBGcmksIDMwIEp1
bCAyMDA0IDEwOjU3OjQ3IC0wNDAwIFJvZCBLIDxyb2RAMjNuZXQubmV0PiBz
YXQgZG93biwgdGhvdWdodCBsb25nDQphbmQgdGhlbiB3cm90ZToNCg0KPiBZ
b3UgYXJlIGNvcnJlY3QuICBZb3UgY2Fubm90IGhhdmUgYSB0cmFuc2FjdGlv
biBzcGFuIG11bHRpcGxlIHBhZ2VzL3NjcmlwdHMuDQo+IA0KPiByZWluZXIg
cGV0ZXJrZSB3cm90ZToNCj4gDQo+ID4gdGhlcmUgc2VlbXMgdG8gYmUgdmVy
eSBsaXR0bGUgaW5mbyBhcm91bmQgb24gYWN0dWFsbHkgdXNpbmcgDQo+ID4g
dHJhbnNhY3Rpb25zIHdpdGggcG9zdGdyZXMuICBpJ3ZlIHRyaWVkIHRvIGNy
ZWF0ZSBhIHBhZ2UgdGhhdCB3aWxsIA0KPiA+IHRha2UgaW5wdXQgZnJvbSBh
IGZvcm0gYW5kIGluc2VydCBpdCBpbnRvIG15IGRhdGFiYXNlLiAgaXQgd29y
a3MgaWYgaSANCj4gPiBqdXN0IGRvIGl0IHdpdGhvdXQgdHJhbnNhY3Rpb25z
IGJ1dCB3aGVuIGkgdHJ5IHRvIHVzZSB3aXRoIHRoZSBiZWdpbiANCj4gPiBh
bmQgY29tbWl0IHNlY3Rpb25zIG9mIGNvZGUsIGl0IGRvZXNuJ3QgdXBkYXRl
IHRoZSBkYXRhIGJhc2UuICBpJ20gDQo+ID4gZ3Vlc3NpbmcgaXQgaXMgZG9p
bmcgYSByb2xsYmFjayB3aGVuIG15IHBhZ2UgbG9hZHMgaXRzZWxmIGFnYWlu
LiAgY2FuIA0KPiA+IGFueW9uZSBoZWxwIG1lIG91dCBoZXJlID8NCj4gPg0K
PiA+IHRoYW5rcw0KPiA+DQoNCg0KLS0gDQpGcmFuayBGaW5uZXINCg0KSW52
ZW5pdXMgLSBTb2x1dGlvbnMgaW4gTGludXgNCkv2cGZjaGVuc3RyYd9lIDM2
DQo1NzA3MiBTaWVnZW4NClRlbGVmb246IDAyNzEgMjMxIDg2MDYgICAgTWFp
bDogZnJhbmsuZmlubmVyQGludmVuaXVzLm9yZw0KVGVsZWZheDogMDI3MSAy
MzEgODYwOCAgICBXZWI6ICBodHRwOi8vd3d3LmludmVuaXVzLm9yZw0KS2V5
IGZpbmdlcnByaW50ID0gNkE2MCBGQTg1IEY2NzAgNEZDMyBDRDdDICBDRUQ1
IDRGNEMgNzJCMSA1NEFDIDE2NUUNCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0oZW5kIG9mIGJyb2FkY2FzdCktLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0KVElQIDM6IGlmIHBvc3RpbmcvcmVhZGluZyB0aHJvdWdoIFVzZW5l
dCwgcGxlYXNlIHNlbmQgYW4gYXBwcm9wcmlhdGUKICAgICAgc3Vic2NyaWJl
LW5vbWFpbCBjb21tYW5kIHRvIG1ham9yZG9tb0Bwb3N0Z3Jlc3FsLm9yZyBz
byB0aGF0IHlvdXIKICAgICAgbWVzc2FnZSBjYW4gZ2V0IHRocm91Z2ggdG8g
dGhlIG1haWxpbmcgbGlzdCBjbGVhbmx5Cg==
Re: [0.0] Re: [0.2] getting transactions to work
am 31.07.2004 11:15:25 von zedaardv
thanks for all the feed back
at least now i have a better idea on how to proceede.
r
On 30 jul 2004, at 20.48, Thom Dyson wrote:
>
>
>
>
> Under PHP (or any cgi type of process), postgres sessions cannot cross
> multiple html pages. This is neither a flaw in PHP nor postgres; it
> is a
> fact that is database and language independent.
>
> Each page submission, that is each php invocation, starts a session
> that is
> closed when the php script is done. the stateless nature of HTTP is at
> the
> heart of this. A web server sees each page request as a stand alone
> event,
> with no relationship to any other request. The ability to do
> "sessions" is
> the work around to this.
>
> So, if you need to carry information from one web page to another , you
> either have to write hidden values to the html page (a bad idea on
> sorts of
> levels) or use session variables to that PHP/postgres can retain
> information.
>
> Thom Dyson
> Director of Information Services
> Sybex, Inc.
>
>
>
> pgsql-php-owner@postgresql.org wrote on 07/30/2004 09:57:53 AM:
>
>> i never said oracle did do that.
>> i don 't have so much experience working with databases and web pages
>> i do not have any understanding or misunderstanding. i am trying to
>> learn how it does work here. to my mind it should be able to work
>> within a web page. maybe you could be so kind as to explain to me why
>> it does not work.
>
>> r
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
> majordomo@postgresql.org
>
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
Re: [0.2] getting transactions to work
am 06.08.2004 12:02:13 von Marco Colombo
reiner peterke wrote:
> well i've read about this thing called persistent connection,
> i think it is supposed to exist in mysql also. the idea sound like what
> i want. i've tried it but i didn't get any different results. but then
> i'm not convinced i did it right either.
You have to face the fact that HTTP is _stateless_. Any common HTTP server
will obey to that, thus destroying any resource related to the request it
just served, _or_ making it appear as if it was destroyed. You really need to
think hard of the implications here.
Persistent connections are no exception: they are just a way to boost
perfermance, but there should be no visible difference at application
level. That is, you should be able to change pg_connect()'s with
pg_pconnect()'s (and vice versa) without changing anything else in your
PHP scripts. Persistent connections add _no_ extra functionality to your
PHP application.
Transactions exist at SQL session level. A "session" is inherently
statefull, and will be destroyed (or made appear as destroyed) at the end
for each HTTP request, because it _has_ to appear stateless. The request
for the 'next' page may be served by a different process, or a even a
different host, so no state can be shared. There's simply no way you can
control this.
Sessions/cookies alone won't let you use transactions, they'll just
emulate them. You can delay the transaction till the final page, but
it's just not the same.
Of course, you can write your own HTTP server (there are simple-to-use Perl
or Python modules to do that) that deliberately fails to adhere to the
HTTP model, and keeps some state. If you control all the environment, that
may even work.
One possible solution is to write proxy application (a server), which talks
on one side to the SQL db and on the other to the PHP frontend.
..TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Re: [0.2] getting transactions to work
am 06.08.2004 19:56:14 von bruce
actually, mod_perl is "supposed" to allow a web app to be written such that
the db connections are resident in memory, and therefore, available to
multiple pages across the web app for a given session....
i haven't tried/tested this, but i've heard that it is supposed to be
possible.
i've had an email exchange with one of the mysql developers who states that
this kind of functionality wil be built into the mysql app and should be
available within the next 3-4 months...
regards,
-----Original Message-----
From: pgsql-php-owner@postgresql.org
[mailto:pgsql-php-owner@postgresql.org]On Behalf Of Marco Colombo
Sent: Friday, August 06, 2004 3:02 AM
To: reiner peterke
Cc: pgsql-php@postgresql.org
Subject: Re: [0.2] [PHP] getting transactions to work
reiner peterke wrote:
> well i've read about this thing called persistent connection,
> i think it is supposed to exist in mysql also. the idea sound like what
> i want. i've tried it but i didn't get any different results. but then
> i'm not convinced i did it right either.
You have to face the fact that HTTP is _stateless_. Any common HTTP server
will obey to that, thus destroying any resource related to the request it
just served, _or_ making it appear as if it was destroyed. You really need
to
think hard of the implications here.
Persistent connections are no exception: they are just a way to boost
perfermance, but there should be no visible difference at application
level. That is, you should be able to change pg_connect()'s with
pg_pconnect()'s (and vice versa) without changing anything else in your
PHP scripts. Persistent connections add _no_ extra functionality to your
PHP application.
Transactions exist at SQL session level. A "session" is inherently
statefull, and will be destroyed (or made appear as destroyed) at the end
for each HTTP request, because it _has_ to appear stateless. The request
for the 'next' page may be served by a different process, or a even a
different host, so no state can be shared. There's simply no way you can
control this.
Sessions/cookies alone won't let you use transactions, they'll just
emulate them. You can delay the transaction till the final page, but
it's just not the same.
Of course, you can write your own HTTP server (there are simple-to-use Perl
or Python modules to do that) that deliberately fails to adhere to the
HTTP model, and keeps some state. If you control all the environment, that
may even work.
One possible solution is to write proxy application (a server), which talks
on one side to the SQL db and on the other to the PHP frontend.
..TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster