We were talking about this a while back and I believe came to a consensus about having two different ZMySQL adapters, one for transactions, one for not. However, since each table can have a different type, this might not bode too well for someone that needs a connection to draw from one table with BDB and one without. If you look at the output of the mysqldump utility, using --opt, it shows both server version and table type. I think we should be able to add a function to _mysql.c that would expose that information on a per-table basis. We could then make the call as to whether the sever supports transactions or not. A question would be, what should the commit/rollback mechanism decide to do when the transaction deals with tables of both types. I would suggest a default behavior of not allowing transactions in a mixed type situation, with a way to set an overriding option to allow the rollbackable table to be rolled back and leave the other as is. Hopefully the application designed wouldn't cause that kind of insanity, but hey, if they want to, they'll find a way. Does anyone have any thoughts on this approach? Baring any blaring negative comments, I'll start working on knocking up something like this. Monty
On Tue, 1 Aug 2000, Monty Taylor wrote:
A question would be, what should the commit/rollback mechanism decide to do when the transaction deals with tables of both types.
It should raise ProgrammingError, "You're screwed". If you need transactional capabilities, then you just can't mix transactional and non-transactional tables in MySQL. This is also why I think there need to be two Zope DAs for MySQL: Non-transactional and transactional, the latter being a simple subclass of the former with TM support mixed-in. The choice of whether or not to be transactional should be made by the application designer; it's too complicated to make at run-time (i.e. for each query). Even if you can use the API to find the table type, you stil have to figure out what tables are used by the query, and that requires parsing SQL. -- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d "Therefore, sweet knights, if you may doubt your strength or courage, come no further, for death awaits you all, with nasty, big, pointy teeth!"
Good point. It still irks me to have two DA's though. It gets confusing enough with the three different DA's running around now, much less if one of them actually had two valid versions. What if we had two classes like you said, but then in the manage_addForm had a checkbox for Transactions enabled, which would determine which Class got instantiated? Any good reasons why that shouldn't work? Monty Andy Dustman wrote:
On Tue, 1 Aug 2000, Monty Taylor wrote:
A question would be, what should the commit/rollback mechanism decide to do when the transaction deals with tables of both types.
It should raise ProgrammingError, "You're screwed".
If you need transactional capabilities, then you just can't mix transactional and non-transactional tables in MySQL. This is also why I think there need to be two Zope DAs for MySQL: Non-transactional and transactional, the latter being a simple subclass of the former with TM support mixed-in. The choice of whether or not to be transactional should be made by the application designer; it's too complicated to make at run-time (i.e. for each query). Even if you can use the API to find the table type, you stil have to figure out what tables are used by the query, and that requires parsing SQL.
-- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d "Therefore, sweet knights, if you may doubt your strength or courage, come no further, for death awaits you all, with nasty, big, pointy teeth!"
At 05:05 PM 8/1/00 +0200, Monty Taylor wrote:
Good point. It still irks me to have two DA's though. It gets confusing enough with the three different DA's running around now, much less if one of them actually had two valid versions. What if we had two classes like you said, but then in the manage_addForm had a checkbox for Transactions enabled, which would determine which Class got instantiated? Any good reasons why that shouldn't work?
Nope. Since Zope constructors are generally implemented as functions, they can actually create any class at all. Of course, you won't be able to change it later without deleting and re-adding... Btw, do you happen to know whether locking is handled automatically on "BDB/transaction-safe" tables, or do you still have to specify it explicitly?
On Tue, 1 Aug 2000, Monty Taylor wrote:
Good point. It still irks me to have two DA's though. It gets confusing enough with the three different DA's running around now, much less if one of them actually had two valid versions. What if we had two classes like you said, but then in the manage_addForm had a checkbox for Transactions enabled, which would determine which Class got instantiated? Any good reasons why that shouldn't work?
I would prefer that, but I'm not sure it's possible, or at least, I don't have enough Zope zen to figure it out. -- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d "Therefore, sweet knights, if you may doubt your strength or courage, come no further, for death awaits you all, with nasty, big, pointy teeth!"
participants (3)
-
Andy Dustman -
Monty Taylor -
Phillip J. Eby