From: Dennis Heuer <dennis@tr...> - 2004-08-15 15:02:15
your documentation is quite unclear about transactions. It says that SQLite and MySQL don't support transactions. However, both SQLite and MySQL *support* transactions, and the python modules do as well. In the case of MySQL support depends on the table type. MySQLdb checks for that and always succeeds gracefully. However, I don't know if SQLObject supports setting the table type when creating a table.
The documentation does not say if SQLObject at least tries to start a transaction and catches the exception. What is actually happening when I'm using the trans object with SQLite or MySQL?
Please, forSQLObject 0.6, at least try to start the transaction (best based on the supported modules) and provide a way to select the table type for MySQL.
When do you expect the next release of SQLObject?
On Wed, Aug 03, 2005 at 02:05:56PM +0200, M. Dietrich wrote:
> how are thinks going on regarding transactions?
What do you mean?
Oleg Broytmann http://phd.pp.ru/ phd@...
Programmers don't die, they just GOSUB without RETURN.
From: M. Dietrich <mdt@em...> - 2005-08-06 19:21:04
On Wed, Aug 03, 2005 at 04:31:37PM +0400, Oleg Broytmann wrote:
> On Wed, Aug 03, 2005 at 02:05:56PM +0200, M. Dietrich wrote:
> > how are thinks going on regarding transactions?
> What do you mean?
the doc states
Better transaction support -- right now you can use transactions for
the database, but the object isn't transaction-aware, so non-database
persistence won't be able to be rolled back.
i would like to see some kind of merge _lazyUpdate, no auto-commit and
caching and no further need for syncUpdate when commit is used.
someone else wrote a posting regarding caching and threading. this
also involves transactions.