Re: [SQLObject] Reconnect to MySQL
Dan Pascu a écrit : > IMO, I see no reason why a server restart cannot be handled by the same > reconnect feature of the underlying mysql library. From the sqlobject > point of view the situation is the same, no matter if the connection did > timeout or the server was restarted. Once it timeouts a connection ceases > to exist in the server much like when the server is restarted and looses > all the connections. > If the reconnect patch is applied to mysqldb, sqlobject needs no changes > and shouldn't care about handling a restarted server (not that it can > tell if the server died, was restarted or closed the connection because > it was idle, anyway). > > In the end, probably the situation can be handled in sqlobject completely, > if the transaction code takes care not to reconnect, but to raise an > exception. Thus if no transactions are used, then the code can create a > new connection everytime it detects a dead one, but if the connection is > a transaction object in the middle of a transaction then it should just > raise an error. > > However I fail to see the point to reimplement all this logic in sqlobject > when it is already implemented by the mysql library. All that is needed > is to make the reconnect option available to the python level and the > solution is already out there, except that somebody insist on ignoring it > for no good reason. > > What I don't understand is that the mysql team choosed not to reconnect automatically in mysql5 because of transactions to be handled correctly. If this is handled correctly in the mysql API, why don't they just enable it by default? I don't see how the API can handle reconnection in a transaction... - 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
Re: [SQLObject] Reconnect to MySQL
On Tuesday 16 January 2007 17:35, Oleg Broytmann wrote: > On Tue, Jan 16, 2007 at 06:28:53PM +0300, Oleg Broytmann wrote: > > > Further, Dan had also some concerns about transactions. He wrote > > > that if the reconnectiong would happen at MySQLdb level, it could > > > be handled gracefully, but that things will get messed up which the > > > patch to SQLObject, if transactions are involved. > > > >Yes, I remember. This means we have to point everyone to the > > MySQLdb patch instead of implementing anything in SQLObject. > >Well, I see. There are two different problems - connection timeout > and server restart. They have to be handled differently. Connection > timeout has to be handled in the DB API driver. Server restart - in the > SQLObject. IMO, I see no reason why a server restart cannot be handled by the same reconnect feature of the underlying mysql library. From the sqlobject point of view the situation is the same, no matter if the connection did timeout or the server was restarted. Once it timeouts a connection ceases to exist in the server much like when the server is restarted and looses all the connections. If the reconnect patch is applied to mysqldb, sqlobject needs no changes and shouldn't care about handling a restarted server (not that it can tell if the server died, was restarted or closed the connection because it was idle, anyway). In the end, probably the situation can be handled in sqlobject completely, if the transaction code takes care not to reconnect, but to raise an exception. Thus if no transactions are used, then the code can create a new connection everytime it detects a dead one, but if the connection is a transaction object in the middle of a transaction then it should just raise an error. However I fail to see the point to reimplement all this logic in sqlobject when it is already implemented by the mysql library. All that is needed is to make the reconnect option available to the python level and the solution is already out there, except that somebody insist on ignoring it for no good reason. -- 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
Re: [SQLObject] Reconnect to MySQL
As I said before, this approach will mess transactions badly, as it can change the connection in the middle of a transaction and the caller will be unaware of this as there will be no indication of what happened. The reconnect feature that is implemented by the mysql client library knows if the connection was in the middle of a transaction when it was lost and will indicate this error condition after reconnecting, allowing for a safe recovery from the situation, while the approach outlined below doesn't. On Tuesday 16 January 2007 17:09, Oleg Broytmann wrote: > On Tue, Jan 16, 2007 at 03:53:39PM +0100, Dr. Markus Gritsch wrote: > > Unfortunately, I had to further modify the previous patch to get > > reconnected in all cases: The __init__ method of the Iteration class > > has also to use the hack. Further, due to my missing insight into > > the inner workings of SQLObject, I totally neglect the self._pool > > stuff of DBAPI, which (I have the feeling) is not perfect -- > > therefore I labeled the patch to be a hack. > >May be instead of going all the way down the hackish path we could > think of a more generic approach. Let's add an empty (no-op) abstract > method to the DBAPI class > >def wakeup(self, raw_connection): > return raw_connection > > that will be called from getConnection and Iteration. Than > MySQLConnection could overide the method. Something like this: > >def wakeup(self, raw_connection): > try: > raw_connection.ping() > return raw_connection > except MySQLdb.OperationalError, e: > if e.args[0] in ( 2006, 2013 ): # SERVER_GONE or > SERVER_LOST error print 'reconnecting because of', e > conn = self.makeConnection() > return conn > else: > raise > > Oleg. -- 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
Re: [SQLObject] Versioning and doneConstructing
On Tue, 2007-01-16 at 23:55 +0300, Oleg Broytmann wrote: > On Tue, Jan 16, 2007 at 02:14:45PM -0500, David Turner wrote: > > The only way to prevent this is to lock the DB for writing before > > reading > >Not neccessary. There is "Serializeable" transaction isolation level. Oh, right. That would do it. > > I am sure that we need to put inherited row creation inside a > > transaction > >What to do on a backend that lacks transaction support such as MySQL > with non-InnoDB tables? In that case, we cannot prevent other processes from screwing things up. But we can prevent SQLObject from doing so by using an ugly global lock. We can make that lock optional, so that if applications have a better idea, they can implement it. - 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
Re: [SQLObject] Versioning and doneConstructing
On Tue, Jan 16, 2007 at 02:14:45PM -0500, David Turner wrote: > The only way to prevent this is to lock the DB for writing before > reading Not neccessary. There is "Serializeable" transaction isolation level. > I am sure that we need to put inherited row creation inside a > transaction What to do on a backend that lacks transaction support such as MySQL with non-InnoDB tables? Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. - 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
Re: [SQLObject] Versioning and doneConstructing
On Fri, 2007-01-12 at 15:20 +0300, Oleg Broytmann wrote: > On Thu, Jan 11, 2007 at 05:04:55PM -0500, David Turner wrote: > > I really don't like the half-constructing code. > >Me too. I have argued [1] against it but without much success. ;) What I > don't like in it is doneColumn - an additional column that have to be > processed everywhere. >Time to revert the patch? I agree that doneColumn is the problem, and that the patch should be reverted. One idea is to rewrite row creation as follows: 1. begin transaction 2. generate defaults 3. do creation (recursively) 4. end transaction Because a transaction is begun before defaults are generated, nothing can change between default calculation and row creation. Except, not really. Because consider this plausible sequence of events: thread 1: opens transaction selects something (step X) thread 2: opens transaction selects something (step Y) thread 1: creates a row based on data selected in step X This row should invalidate the select in step Y commits thread 2: creates something based on (now incorrect) data selected in step Y commits --- The only way to prevent this is to lock the DB for writing before reading (that is, before generating defaults). But there is (afaict) no standard SQL way to directly lock a table. This may not matter -- we could just write DB-specific ways of doing it as we would for anything else non-standard. --- I don't really have time to write this right now. I'm also not sure it's 100% correct. I am sure that we need to put inherited row creation inside a transaction, because otherwise random aggregate reads will fail. I still don't have time to do this right now. - 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
Re: [SQLObject] When are connections opened and closed?
On Tue, Jan 16, 2007 at 07:09:59PM +0100, Daniel Nogradi wrote: > Thanks very much again. So basically I don't have to worry about > opening and closing the connection at all, right? It is opened > automatically at the first request and closed automatically when the > process ends? Basically, yes. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. - 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
Re: [SQLObject] When are connections opened and closed?
> > I'm sure it's a noobish question, but when are connections opened and > > closed exactly? > >Exactly: they are opened and closed in dbconnection.py, in class DBAPI. > Thanks very much again. So basically I don't have to worry about opening and closing the connection at all, right? It is opened automatically at the first request and closed automatically when the process ends? A more important concern I had is that whether I need to worry about a possible overhead of automatic opening and closing between requests, i.e. can I be sure that there is no unnecessary opening/closing going on behind the scenes? - 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
Re: [SQLObject] Problematic error message using pydoc
On Tue, Jan 16, 2007 at 08:54:07AM -0800, Molly Aplet wrote: > ./sqlobject/main.py:589: DeprecationWarning: Use of this attribute should be > replaced with .sqlmeta.cacheValues > '.sqlmeta.%s' % self.name, level=self.deprecation_level) > ./sqlobject/main.py:589: DeprecationWarning: Use of this attribute should be > replaced with .sqlmeta.columns > '.sqlmeta.%s' % self.name, level=self.deprecation_level) > ./sqlobject/main.py:589: DeprecationWarning: Use of this attribute should be > replaced with .sqlmeta.columnList > '.sqlmeta.%s' % self.name, level=self.deprecation_level) These deprecation warnings are from using '_'-attributes at the SQLObject level: class MyTable(SQLObject): _cacheValues = True They have to be moved inside sqlmeta class: class MyTable(SQLObject): class sqlmeta: cacheValues = True Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. - 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
[SQLObject] Problematic error message using pydoc
I'm attempting to use pydoc to document a class that inherits from SQLObject. Something in my code is depreciated, causing the error message I've included below. However, I'm having some trouble tracking down exactly what, since I'm not accessing any columns or cached values in the class in question. As you may notice, the line referenced in the warning message is not the line in my code where the exception was thrown but the line in sqlobject/main.py, where the exception was handled. Is there a way to find out what piece of my code threw the warning? BAD BAD BAD BAD CONFIGURATION ./sqlobject/main.py:589: DeprecationWarning: Use of this attribute should be replaced with .sqlmeta.cacheValues '.sqlmeta.%s' % self.name, level=self.deprecation_level) ./sqlobject/main.py:589: DeprecationWarning: Use of this attribute should be replaced with .sqlmeta.columns '.sqlmeta.%s' % self.name, level=self.deprecation_level) ./sqlobject/main.py:589: DeprecationWarning: Use of this attribute should be replaced with .sqlmeta.columnList '.sqlmeta.%s' % self.name, level=self.deprecation_level) Thanks, Molly - 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
Re: [SQLObject] Reconnect to MySQL
On Tue, Jan 16, 2007 at 06:28:53PM +0300, Oleg Broytmann wrote: > > Further, Dan had also some concerns about transactions. He wrote that > > if the reconnectiong would happen at MySQLdb level, it could be > > handled gracefully, but that things will get messed up which the patch > > to SQLObject, if transactions are involved. > >Yes, I remember. This means we have to point everyone to the MySQLdb > patch instead of implementing anything in SQLObject. Well, I see. There are two different problems - connection timeout and server restart. They have to be handled differently. Connection timeout has to be handled in the DB API driver. Server restart - in the SQLObject. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. - 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
Re: [SQLObject] Reconnect to MySQL
On Tue, Jan 16, 2007 at 04:22:16PM +0100, Dr. Markus Gritsch wrote: > Sounds quite ok. And, BTW, there is an unexplored SolidConnection from DBUtil. I just remembered I have to look into it. > Still, have you any opinion about the pooling-stuff? It has to be preserved, I think. > Further, Dan had also some concerns about transactions. He wrote that > if the reconnectiong would happen at MySQLdb level, it could be > handled gracefully, but that things will get messed up which the patch > to SQLObject, if transactions are involved. Yes, I remember. This means we have to point everyone to the MySQLdb patch instead of implementing anything in SQLObject. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. - 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
Re: [SQLObject] Reconnect to MySQL
On 1/16/07, Oleg Broytmann <[EMAIL PROTECTED]> wrote: > On Tue, Jan 16, 2007 at 03:53:39PM +0100, Dr. Markus Gritsch wrote: > > Unfortunately, I had to further modify the previous patch to get > > reconnected in all cases: The __init__ method of the Iteration class > > has also to use the hack. Further, due to my missing insight into the > > inner workings of SQLObject, I totally neglect the self._pool stuff of > > DBAPI, which (I have the feeling) is not perfect -- therefore I > > labeled the patch to be a hack. > >May be instead of going all the way down the hackish path we could think > of a more generic approach. Let's add an empty (no-op) abstract method to > the DBAPI class > >def wakeup(self, raw_connection): > return raw_connection > > that will be called from getConnection and Iteration. Than MySQLConnection > could overide the method. Something like this: > >def wakeup(self, raw_connection): > try: > raw_connection.ping() > return raw_connection > except MySQLdb.OperationalError, e: > if e.args[0] in ( 2006, 2013 ): # SERVER_GONE or SERVER_LOST error > print 'reconnecting because of', e > conn = self.makeConnection() > return conn > else: > raise Sounds quite ok. Still, have you any opinion about the pooling-stuff? Further, Dan had also some concerns about transactions. He wrote that if the reconnectiong would happen at MySQLdb level, it could be handled gracefully, but that things will get messed up which the patch to SQLObject, if transactions are involved. Kind regard, Markus - 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
Re: [SQLObject] Reconnect to MySQL
On Tue, Jan 16, 2007 at 03:53:39PM +0100, Dr. Markus Gritsch wrote: > Unfortunately, I had to further modify the previous patch to get > reconnected in all cases: The __init__ method of the Iteration class > has also to use the hack. Further, due to my missing insight into the > inner workings of SQLObject, I totally neglect the self._pool stuff of > DBAPI, which (I have the feeling) is not perfect -- therefore I > labeled the patch to be a hack. May be instead of going all the way down the hackish path we could think of a more generic approach. Let's add an empty (no-op) abstract method to the DBAPI class def wakeup(self, raw_connection): return raw_connection that will be called from getConnection and Iteration. Than MySQLConnection could overide the method. Something like this: def wakeup(self, raw_connection): try: raw_connection.ping() return raw_connection except MySQLdb.OperationalError, e: if e.args[0] in ( 2006, 2013 ): # SERVER_GONE or SERVER_LOST error print 'reconnecting because of', e conn = self.makeConnection() return conn else: raise Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. - 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
Re: [SQLObject] Reconnect to MySQL (was: Regression in SQLObject 0.8.0b1)
On 1/16/07, Oleg Broytmann <[EMAIL PROTECTED]> wrote: > On Sat, Dec 30, 2006 at 04:29:41PM +0100, Markus Gritsch wrote: > > Just FYI: I made a small hack to my local SQLObject which solves the > > reconnect problem for me without recompiling MySQLdb. The patch is > > attached, but as already said, it's just a hack. Thanks to anyone > > involved. > >Could that _runWithConnection() be copied to mysqlconnection.py? Then it > could be applied. Furthermore I have the feeling, that the correct level to make a change would be in MySQLdb. It is sad that there is a perfect patch available for MySQLdb but nevertheless Andy Dustman is not going to apply it. Dan made it very clear http://pythonpaste.org/archives/message/20061230.164647.05206e69.en.html Kind regards, Markus - 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
Re: [SQLObject] Reconnect to MySQL (was: Regression in SQLObject 0.8.0b1)
On 1/16/07, Oleg Broytmann <[EMAIL PROTECTED]> wrote: On Sat, Dec 30, 2006 at 04:29:41PM +0100, Markus Gritsch wrote: > Just FYI: I made a small hack to my local SQLObject which solves the > reconnect problem for me without recompiling MySQLdb. The patch is > attached, but as already said, it's just a hack. Thanks to anyone > involved. Could that _runWithConnection() be copied to mysqlconnection.py? Then it could be applied. Unfortunately, I had to further modify the previous patch to get reconnected in all cases: The __init__ method of the Iteration class has also to use the hack. Further, due to my missing insight into the inner workings of SQLObject, I totally neglect the self._pool stuff of DBAPI, which (I have the feeling) is not perfect -- therefore I labeled the patch to be a hack. However, if you could look at the attached final patch and have any idea if neglecting the self._pool stuff is ok, that would be nice. Kind regards, Markus sqlobject-0.8.0b1.patch Description: Binary data - 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
Re: [SQLObject] Additional database connection parameters
Applied to docs and committed in the revision 2207. Thank you! On Mon, Jan 15, 2007 at 09:03:03AM +0100, Felix Schwarz wrote: > import MySQLdb.converters > import sqlobject > import time > > def _mysql_timestamp_converter(raw): > """Convert a MySQL TIMESTAMP to a floating point number representing > the seconds since the Un*x Epoch. It uses custom code the input > seems > to be the new (MySQL 4.1+) timestamp format, otherwise code from the > MySQLdb module is used.""" > if raw[4] == '-': > return time.mktime(time.strptime(raw, '%Y-%m-%d %H:%M:%S')) > else: > return MySQLdb.converters.mysql_timestamp_converter(raw) > > conversions = MySQLdb.converters.conversions.copy() > conversions[MySQLdb.constants.FIELD_TYPE.TIMESTAMP] = > _mysql_timestamp_converter > > MySQLConnection = sqlobject.mysql.builder() > connection = MySQLConnection(user='foo', db='somedb', conv=conversions) Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. - 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
Re: [SQLObject] Additional database connection parameters
On Wed, Jan 10, 2007 at 06:33:36PM +0100, Felix Schwarz wrote: > connection = MySQLConnection(user='root', db='xamstest', port=0) > > Therefore I propose changing the default value of __init__ to be "0" and > not "None". Applied and committed in the revision 2205. > And now the changes outlined in my previous mail in order to support the > conv keyword for MySQL do indeed work as expected. See conv.patch. Applied and committed in the revision 2206. Thank you! Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. - 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
Re: [SQLObject] Reconnect to MySQL (was: Regression in SQLObject 0.8.0b1)
On Sat, Dec 30, 2006 at 04:29:41PM +0100, Markus Gritsch wrote: > Just FYI: I made a small hack to my local SQLObject which solves the > reconnect problem for me without recompiling MySQLdb. The patch is > attached, but as already said, it's just a hack. Thanks to anyone > involved. Could that _runWithConnection() be copied to mysqlconnection.py? Then it could be applied. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. - 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
Re: [SQLObject] When are connections opened and closed?
On Tue, Jan 16, 2007 at 05:46:46AM +0100, Daniel Nogradi wrote: > I'm sure it's a noobish question, but when are connections opened and > closed exactly? Exactly: they are opened and closed in dbconnection.py, in class DBAPI. > -- > from sqlobject import * > > con = connectionForURI( 'sqlite:/:memory:' ) > sqlhub.processConnection = con > > class t( SQLObject ): > c = StringCol( ) > > t.createTable( ) > # now is it open? Yes. > t( c='1' ) > # now is it open? Yes. > t( c='2' ) > t( c='3' ) > t( c='4' ) > t( c='5' ) > # now is it open? Yes. > s = t.select( ) > for i in s: > print i Yes. > # now is it open? > print s.count( ) > # now is it open? Yes. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. - 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
