Hi Michael
OK, I've invested (wasted?) my entire day on this connection issue and have the
following to report. Hopefully, the hints I've managed to find may trigger
something with you that will point me in the right direction.
In recap; the issue was I could not get a simple engine to connect to the MySQL
database. This used to work on this server with the current configuration and
simply seemed to stop working.
e = create_engine('mysql+mysqlconnector://user:passw...@127.0.0.1/testdb',
encoding='utf8', echo=False)
e.connect()
(Traceback below from previous messages)
So, I followed all the code through and found that it actually failing at the
point where in cursor.py it's attempting to create a new cursor.
def set_connection(self, db):
try:
if isinstance(db.conn.protocol,protocol.MySQLProtocol):
self.db = weakref.ref(db)
if self not in self.db().cursors:
self.db().cursors.append(self)
except Exception as message:
raise errors.InterfaceError(errno=2048)
The db appears to be correct (I looked), protocol.MySQLProtocol appears to be
correct BUT db.conn = None ! Therefore it raises 2048
So, after many hours I can not find where db.conn is set or what it is supposed
to be in the first place! Note: I have a virtually identical setup on my XP
VM, and the same example of engine.connect() works fine.
What I'm looking for is a little info on what db.conn should be, where is it
set, how can it be NOT set etc. Your help would be most appreciated.
Incidentally, all was not a waste of time as I traversed nearly ALL of the SA
code today and picked up a few nice tips.. Thanks! :-)
Cheers
Warwick
Warwick Prince
Managing Director
mobile: +61 411 026 992
skype: warwickprince
phone: +61 7 3102 3730
fax: +61 7 3319 6734
web: www.mushroomsys.com
On 26/08/2010, at 3:37 PM, Michael Bayer wrote:
>
> On Aug 25, 2010, at 11:09 PM, Warwick Prince wrote:
>
>> HI Michael
>>
>> Excellent. Thanks for the pointers - I'll investigate further and get back
>> to you. This is really strange as I do not believe that I changed anything
>> from the point it all worked, to the point at which it didn't! (I'm sure
>> there will be something however - there always is..). :-) I'll let you
>> know how I go. When I get it going again, I'll hit you with the REAL
>> questions I have..
>
> those connection issues are fixed in tip (not your MySQL problem, though).
>
>
>>
>> Cheers
>> Warwick
>>
>> On 26/08/2010, at 12:43 PM, Michael Bayer wrote:
>>
>>>
>>> On Aug 25, 2010, at 10:11 PM, Warwick Prince wrote:
>>>
>>>> Hi All
>>>>
>>>> This is my first post here, so I wish it were a little more spectacular..
>>>> :-)
>>>>
>>>> I have been working happily with SA 0.6.x on Windows 2003 server with
>>>> MySQL and the Sun Python Connector. I have an identical config running
>>>> (and working) on XP.
>>>>
>>>> I was testing my code which had been working perfectly, and suddenly
>>>> started getting this message which I had never seen before;
>>>>
>>>> Traceback (most recent call last):
>>>> File "<pyshell#3>", line 1, in <module>
>>>> e.connect()
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\engine\base.py", line 1731,
>>>> in connect
>>>> return self.Connection(self, **kwargs)
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\engine\base.py", line 821,
>>>> in __init__
>>>> self.__connection = connection or engine.raw_connection()
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\engine\base.py", line 1787,
>>>> in raw_connection
>>>> return self.pool.unique_connection()
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\pool.py", line 135, in
>>>> unique_connection
>>>> return _ConnectionFairy(self).checkout()
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\pool.py", line 329, in
>>>> __init__
>>>> rec = self._connection_record = pool.get()
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\pool.py", line 177, in get
>>>> return self.do_get()
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\pool.py", line 692, in
>>>> do_get
>>>> con = self.create_connection()
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\pool.py", line 138, in
>>>> create_connection
>>>> return _ConnectionRecord(self)
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\pool.py", line 218, in
>>>> __init__
>>>> l.first_connect(self.connection, self)
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\engine\strategies.py", line
>>>> 145, in first_connect
>>>> dialect.initialize(c)
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\dialects\mysql\base.py",
>>>> line 1774, in initialize
>>>> default.DefaultDialect.initialize(self, connection)
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\engine\default.py", line
>>>> 144, in initialize
>>>> self._get_default_schema_name(connection)
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\dialects\mysql\base.py",
>>>> line 1739, in _get_default_schema_name
>>>> return connection.execute('SELECT DATABASE()').scalar()
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\engine\base.py", line 1157,
>>>> in execute
>>>> params)
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\engine\base.py", line 1252,
>>>> in _execute_text
>>>> parameters=parameters)
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\engine\base.py", line 1348,
>>>> in __create_execution_context
>>>> None, None)
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\engine\base.py", line 1311,
>>>> in _handle_dbapi_exception
>>>> self.invalidate(e)
>>>> File "C:\Python26\lib\site-packages\sqlalchemy\engine\base.py", line 961,
>>>> in invalidate
>>>> if self.__connection.is_valid:
>>>> AttributeError: 'MySQL' object has no attribute 'is_valid'
>>>>
>>>> I have spent a significant amount of time on this, and nothing makes
>>>> sense. I've run the unittest.py code that comes with the connector, and
>>>> (connecting to the same DB) ran the tests with success. Firstly, it would
>>>> appear that there is a possible bug in base.py at line 962 where it asks "
>>>> if self.__connection.is_valid:" as this attribute has not been created
>>>> yet, and is conditionally created.
>>>
>>> __connection is created in the constructor, and it may get del'ed by close
>>> or invalidate. There's a check for closed right there, so its only if
>>> invalidate() is called twice that there'd be an issue. But that's not
>>> what's happening here, since __connection is present.
>>>
>>> Its still a bug on our part though, partially, there's an edge case where
>>> the __connection member is not the usual ConnectionFairy wrapper we use,
>>> and is the raw DBAPI connection, and that is during the initilization phase
>>> of a new connection. In your stack trace, a new connection is acquired
>>> from the DBAPI, and we're calling "SELECT DATABASE()" on it. That is
>>> failing. Very unusually, it is failing with an exception that passes the
>>> "is_disconnect" test, which means the errno is in (2006, 2013, 2014, 2045,
>>> 2055, 2048) according to the mysqlconnector dialect, and means the
>>> connection has been lost. Interestingly, that is one more code than we
>>> have in base.py. So that list of codes is suspect (the myconnpy guys
>>> provided some of this code) - the base list used by the other MySQL
>>> dialects is (2006, 2013, 2014, 2045, 2055).
>>>
>>> The exception then passes off to invalidate() which wasn't expecting a raw
>>> DBAPI connection and it breaks. Ticket #1894 is added.
>>>
>>> For the immediate issue you'd need to figure out what error SELECT
>>> DATABASE() is returning.
>>>
>>>
>>>
>>>
>>>> However, this is not the root of the issue, merely a distraction. (I
>>>> forced this to exist and have a value, but the problem just fell through
>>>> to further down the code)
>>>>
>>>> I can get this error by simply doing this (now) when this all has worked
>>>> for days.
>>>>
>>>> e = create_engine('mysql+mysqlconnector://user:passw...@127.0.0.1/testdb',
>>>> encoding='utf8', echo=False)
>>>> e.connect()
>>>>
>>>> Any clues - as this is driving me nuts! Can't do ANYTHING now because I
>>>> an no longer connect to the DB. DB manager and other tools all show MySQL
>>>> happily ticking along. I have rebooted the server.
>>>>
>>>> As a possible solution, are there any other stable MySQL connectors out
>>>> there that are easy to install on a Windows platform? The Python
>>>> Connector one chosen has been good so far, but if that turns out to be
>>>> the issue - it's gone!
>>>>
>>>> Cheers
>>>> Warwick
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "sqlalchemy" group.
>>>> To post to this group, send email to sqlalch...@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> sqlalchemy+unsubscr...@googlegroups.com.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/sqlalchemy?hl=en.
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "sqlalchemy" group.
>>> To post to this group, send email to sqlalch...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> sqlalchemy+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/sqlalchemy?hl=en.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sqlalchemy" group.
>> To post to this group, send email to sqlalch...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sqlalchemy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sqlalchemy?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To post to this group, send email to sqlalch...@googlegroups.com.
> To unsubscribe from this group, send email to
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
