Re: [Zope] Summary of DB Discussion
On Wed, Nov 10, 1999 at 09:46:43AM -0500, Phillip J. Eby wrote:
At 06:31 PM 11/9/99 -0600, Karl Fast wrote:
- Despite it's lack of transaction support, it was agreed that MySQL (a) is popular (b) is very fast and a good choice for sites that do high volume queries, but relatively simple and low-volume updates (c) will be getting transaction support "real soon now" according to the web site (d) should have a good, up to date, Zope DA
Could anyone point out where the "real soon now" is on the site? Every time I've ever looked at the site it has said that they have no plans to implement fully ACID transactions, ever.
This page has a list of things they want to do, broken down into 3 sections: 1. Things that must be done in the real near future 2. Things that have to be done sometime 3. Something we don't have any plans to do http://www.mysql.com/Manual_chapter/manual_TODO.html#TODO Under #1 the first two items are "one way replication" and "transactions" Under #3 there is only one entry: "Transactions with rollback (we mainly do SELECTs, and because we don't do transactions, we can be much quicker on everything else). We will support some kind of atomic operations on multiple tables, though. Currently atomic operations can be done with LOCK TABLES/UNLOCK TABLES but we will make this more automatic in the future." ----------------------------------------------------------------- Karl Fast
At 09:21 AM 11/10/99 -0600, Karl Fast wrote:
On Wed, Nov 10, 1999 at 09:46:43AM -0500, Phillip J. Eby wrote:
Could anyone point out where the "real soon now" is on the site? Every time I've ever looked at the site it has said that they have no plans to implement fully ACID transactions, ever.
This page has a list of things they want to do, broken down into 3 sections:
1. Things that must be done in the real near future 2. Things that have to be done sometime 3. Something we don't have any plans to do
http://www.mysql.com/Manual_chapter/manual_TODO.html#TODO
Under #1 the first two items are "one way replication" and "transactions"
Under #3 there is only one entry:
"Transactions with rollback (we mainly do SELECTs, and because we don't do transactions, we can be much quicker on everything else). We will support some kind of atomic operations on multiple tables, though. Currently atomic operations can be done with LOCK TABLES/UNLOCK TABLES but we will make this more automatic in the future."
That's the kicker. If you don't have rollback, how can you call it a transaction??? Seems to me, that to work with Zope, you need to be able to roll back the transaction if anything on the Zope side fails.
At 17:07 10/11/99 , Phillip J. Eby wrote:
That's the kicker. If you don't have rollback, how can you call it a transaction??? Seems to me, that to work with Zope, you need to be able to roll back the transaction if anything on the Zope side fails.
They have stated that the last entry is a mistake. It should be removed. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
That's the kicker. If you don't have rollback, how can you call it a transaction??? Seems to me, that to work with Zope, you need to be able to roll back the transaction if anything on the Zope side fails.
They have stated that the last entry is a mistake. It should be removed.
When I read that I thought, hey, this is wierd. Why bother with transactions and not rollbacks. Then I wondered if maybe it was a mistake and they hadn't updated the page. So transactions and rollbacks are high on their list then. That shouldn't be a big surprise since it's definitely the biggest complaint people have about it. thanks for the info.... ----------------------------------------------------------------- Karl Fast
On 11/10/99 11:07 AM, Phillip J. Eby at pje@telecommunity.com wrote:
That's the kicker. If you don't have rollback, how can you call it a transaction??? Seems to me, that to work with Zope, you need to be able to roll back the transaction if anything on the Zope side fails.
If it can not be aborted, rolled back and commited, it's not a transaction, no matter what you call it. This is what I read on their site, perhaps I simply don't see things I wish to see :-) Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
participants (4)
-
Christopher Petrilli -
Karl Fast -
Martijn Pieters -
Phillip J. Eby