On Saturday 30 December 2006 12:00, Markus Gritsch wrote: > By reading Andy Dustmans (creator and maintainer of MySQLdb) reply at > http://sourceforge.net/forum/forum.php?thread_id=1639447&forum_id=70461 > it is quite unlikely that a readily available patch, which would > implement this, will be applied.
Unfortunately I had a similar negative experience with Andy Dustman regarding the same issue. The patch I made for the debian, was also sent to Andy, but was rejected because it did hardcode the reconnect value to true making it behave like before. Here I was in agreement with him that it was not a good idea to hardcode the value, but instead provide a connection option which should default to false and he agreed that this solution would satisfy him. I didn't had time to elaborate on this, so I left it alone for a while, just to come back later and find that someone else implemented exactly the solution that Andy claimed would satisfy him, but this proper solution was rejected as well for no valid reason. Andy's claim that it affects transactions is false. Transactions can recover from a reconnect and this is clearly stated in the mysql manual. The reason why mysql >= 5.0.13 did turn off the reconnect flag were not transactions (there were transactions in 4.x as well), but the fact that 5.x introduced views, stored procedures and connection variables. All these are attached to a connection and will be lost if the connection is lost and reconnected (views, temporary tables and session variables will dissapear and there will be no indication of this). Transactions on the other hand can recover from this because they will detect the situation. So I really do not understand why Andy is so much against adding this option which would allow people who do not use views, temporary tables and session variables to still enable the reconnect feature without an ill effects. And SQLObject is exactly in this case where it can enable reconnecting without ill effects. > > Wouldn't it be possible to do a reconnect at SQLObject-level? At > http://www.mail-archive.com/turbogears-tickets@googlegroups.com/msg0184 >2.html there is a "quick dirty hack on SQLObject". I do not think that will work. If you use transactions, they are tied to a connection which was lost and not reconnected. Even if it will be reconnected, you won't know and you may commit just half of your transaction without knowing and with no error indication. If the connection is restored at the mysql lib level, it'll know that before being lost it was in the middle of a transaction and will return an error indication that the transaction was interrupted by a reconnect and should be restarted, thus allowing for a transaction to recover. The approach outlined in the above link doesn't handle this and silently hides such errors if you use transactions. -- Dan ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ sqlobject-discuss mailing list sqlobject-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
