pypgsql-devel

[Pypgsql-devel] [ pypgsql-Patches-738712 ] inTransaction not updated when committing a large object

[SourceForge.net <no...@so...>]

Patches item #738712, was opened at 2003-05-16 12:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=738712&group_id=16528

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Laurent Pinchart (peter_pan78)
Assigned to: Nobody/Anonymous (nobody)
Summary: inTransaction not updated when committing a large object

Initial Comment:
If not transaction is in progress when creating a new
large object, Connection.binary setups a new
transaction, which sets the internal variable
inTransaction to 1. The transaction is commited at the
end of Connection.binary, but inTransaction is not set
back to 0 as it should.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=738712&group_id=16528

[Pypgsql-devel] [ pypgsql-Patches-738712 ] inTransaction not updated when committing a large object

[SourceForge.net <no...@so...>]

Patches item #738712, was opened at 2003-05-16 06:02
Message generated for change (Comment added) made by ballie01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=738712&group_id=16528

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Laurent Pinchart (peter_pan78)
Assigned to: Nobody/Anonymous (nobody)
Summary: inTransaction not updated when committing a large object

Initial Comment:
If not transaction is in progress when creating a new
large object, Connection.binary setups a new
transaction, which sets the internal variable
inTransaction to 1. The transaction is commited at the
end of Connection.binary, but inTransaction is not set
back to 0 as it should.

----------------------------------------------------------------------

>Comment By: Billy G. Allie (ballie01)
Date: 2003-05-19 13:43

Message:
Logged In: YES 
user_id=8500

After some thought, I now believe that the transaction should 
not be committed after the large object is created.  This 
would push the responsibility of commiting the transactiont to 
the application programmer.  The sequence would usally be:

1. (optionally) perform some queries or updates.
1. create the large object.
2  store the new large object in a table
3 (optionally) perform other queries and updates.
4 commit (or rollback) the transaction.

This change will allow the creation of the large object to be 
rolled back if a problem occurs after it's creation.  Currently, 
the large object is commited before it is returned to the 
application, which, IMHO, is not the way it should be.

Commets anyone?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=738712&group_id=16528

[Pypgsql-devel] [ pypgsql-Patches-738712 ] inTransaction not updated when committing a large object

[SourceForge.net <no...@so...>]

Patches item #738712, was opened at 2003-05-16 06:02
Message generated for change (Settings changed) made by ballie01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=738712&group_id=16528

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Laurent Pinchart (peter_pan78)
>Assigned to: Billy G. Allie (ballie01)
Summary: inTransaction not updated when committing a large object

Initial Comment:
If not transaction is in progress when creating a new
large object, Connection.binary setups a new
transaction, which sets the internal variable
inTransaction to 1. The transaction is commited at the
end of Connection.binary, but inTransaction is not set
back to 0 as it should.

----------------------------------------------------------------------

Comment By: Billy G. Allie (ballie01)
Date: 2003-05-19 13:43

Message:
Logged In: YES 
user_id=8500

After some thought, I now believe that the transaction should 
not be committed after the large object is created.  This 
would push the responsibility of commiting the transactiont to 
the application programmer.  The sequence would usally be:

1. (optionally) perform some queries or updates.
1. create the large object.
2  store the new large object in a table
3 (optionally) perform other queries and updates.
4 commit (or rollback) the transaction.

This change will allow the creation of the large object to be 
rolled back if a problem occurs after it's creation.  Currently, 
the large object is commited before it is returned to the 
application, which, IMHO, is not the way it should be.

Commets anyone?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=738712&group_id=16528

[Pypgsql-devel] [ pypgsql-Patches-738712 ] inTransaction not updated when committing a large object

[SourceForge.net <no...@so...>]

Patches item #738712, was opened at 2003-05-16 06:02
Message generated for change (Settings changed) made by ballie01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=738712&group_id=16528

Category: None
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 7
Submitted By: Laurent Pinchart (peter_pan78)
Assigned to: Billy G. Allie (ballie01)
Summary: inTransaction not updated when committing a large object

Initial Comment:
If not transaction is in progress when creating a new
large object, Connection.binary setups a new
transaction, which sets the internal variable
inTransaction to 1. The transaction is commited at the
end of Connection.binary, but inTransaction is not set
back to 0 as it should.

----------------------------------------------------------------------

>Comment By: Billy G. Allie (ballie01)
Date: 2003-06-03 23:20

Message:
Logged In: YES 
user_id=8500

As I recieved no comments one way or the other, I implement
the change I described earlier.

----------------------------------------------------------------------

Comment By: Billy G. Allie (ballie01)
Date: 2003-05-19 13:43

Message:
Logged In: YES 
user_id=8500

After some thought, I now believe that the transaction should 
not be committed after the large object is created.  This 
would push the responsibility of commiting the transactiont to 
the application programmer.  The sequence would usally be:

1. (optionally) perform some queries or updates.
1. create the large object.
2  store the new large object in a table
3 (optionally) perform other queries and updates.
4 commit (or rollback) the transaction.

This change will allow the creation of the large object to be 
rolled back if a problem occurs after it's creation.  Currently, 
the large object is commited before it is returned to the 
application, which, IMHO, is not the way it should be.

Commets anyone?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=316528&aid=738712&group_id=16528