Webware for Python

There is a long standing problem that MiddleKit doesn't like MySQLdb 0.9.2,=
 although it gets along great with 0.9.1 and many versions prior. Under=
 MySQLdb 0.9.2, some of the MiddleKit tests yield "Too many connections":

[snip]
File "C:\All\echuck\Projects\Webware\MiddleKit\Run\MySQLObjectStore.py",=
 line 34, in newConnection
    conn =3D self.dbapiModule().connect(**args)
  File "C:\Python23\Lib\site-packages\MySQLdb\__init__.py", line 63, in=
 Connect
    return apply(Connection, args, kwargs)
  File "C:\Python23\Lib\site-packages\MySQLdb\connections.py", line 115, in=
 __init__
    self._make_connection(args, kwargs2)
  File "C:\Python23\Lib\site-packages\MySQLdb\connections.py", line 41, in=
 _make_connection
    apply(super(ConnectionBase, self).__init__, args, kwargs)
OperationalError: (1040, 'Too many connections')

In fact, here are the results:

RESULTS
-------
     succeeded MKBasic.mkmodel
     succeeded MKNone.mkmodel
     succeeded MKString.mkmodel
     succeeded MKDateTime.mkmodel
     succeeded MKDefaultMinMax.mkmodel
     succeeded MKTypeValueChecking.mkmodel
     succeeded MKInheritance.mkmodel
     succeeded MKInheritanceAbstract.mkmodel
     succeeded MKList.mkmodel
     succeeded MKObjRef.mkmodel
     succeeded MKObjRefReuse.mkmodel
*** FAILED *** MKDelete.mkmodel
*** FAILED *** MKDeleteMark.mkmodel
     succeeded MKMultipleStores.mkmodel
*** FAILED *** MKMultipleThreads.mkmodel
     succeeded MKModelInh1.mkmodel
     succeeded MKModelInh2.mkmodel
     succeeded MKModelInh3.mkmodel

This problem is so bad that one of the tests completely freezes and I have=
 to *kill* it with the Task Manager. (Each MK test is run in a separate=
 process, so the main Test.py keeps going with the other ones after any kind=
 of failure.)

IIRC this problem happens under Linux as well, but it would be nice to=
 verify. Also, it happens with both Python 2.2.x and 2.3.x.

I spoke with Andy Dustman, author of MySQLdb, awhile back but didn't=
 convince him it was a MySQLdb flaw (which is still my inclination, but not=
 proven) nor did the two of us come up with any good ideas.

The impact of this problem goes like this: If a new user (or a user with a=
 new machine like me) downloads the latest stable versions of Python,=
 Webware and MySQLdb, then that user will have this problem. Yuk.

Also, MySQLdb doesn't provide a 0.9.1 binary for Python 2.3 so the fix isn't=
 as easy as a download.

Btw I tried this really cheesy fix:
 =09=09=09=09import gc, time
 =09=09=09=09reload(MySQLdb)
 =09=09=09=09gc.collect()
 =09=09=09=09time.sleep(0.5)
with a loop of 5 attempts. No change in results.

And my db server is not used by anything else. It's completely local,=
 private and freshly installed.

I will follow up more on this, but for now it's getting late. I'd appreciate=
 any kind of help on this, even if it's as small as running the test suite=
 on platform X and reporting the results.

Of course, solutions are welcome too.  :-)

So are speculations.

And finally, instructions to run the test suite:
* cd to MiddleKit/Tests
* if you're in cvs: cvs upd -dP
* If needed, edit TestRun.py line 23 from
=09store =3D MySQLObjectStore()
to
=09store =3D MySQLObjectStore(user=3D'foo', passwd=3D'bar')
* If needed, edit Test.py line 28 from
=09=09return 'mysql'
to
=09=09return 'mysql -u foo -pbar'
* Type: python Test.py MKDelete
* or to run all tests, simply: python Test.py

All tests take 75 seconds on my 3GHz P4.

Sorry for the two edits. I plan to factor those out to a config file so you=
 can specify all the info in one place or via command line.


-Chuck
-- 
http://ChuckEsterbrook.com/

I'm back from the dead with new tweaks to MiddleKit in CVS HEAD:

* Attribute names, which must be compatible with Python (since they get used=
 as method names), are now checked against a regex. (MiddleKit/Core/Attr.py=
 __init__())

* Integer overflow error checking is reinstated under Python 2.3. In other=
 words: Fixed the code generation for setSomeInt() to raise OverflowError if=
 the argument cannot be reduced to an int (vs. a long). This is important=
 because databases don't have arbitrarily long longs like Python does. This=
 behavior already exists in MiddleKit under Python <2.3.

* Added MiddleObject.refetch() for refreshing a single object from it's data=
 in the database. It's an experimental method; i.e., I didn't think about it=
 real hard.  :-)

=09def refetch(self):
=09=09"""
=09=09Refetches the object's attributes from the store.
=09=09Only works for non-changed objects from a store.
=09=09@@ not covered by test suite yet
=09=09"""
=09=09assert self.isInStore()
=09=09assert not self.isChanged()
=09=09result =3D self.store().fetchObject(self.__class__, self.serialNum())
=09=09assert result is self, 'expecting result to be self. self=3D%r, result=3D%r' %=
 (self, result)

* Tweaked an assert in MiddleKit.Run.ObjectStore._deleteObject() to be more=
 informative.

* Tweaked MiddleKit/Tests/FixPath to fix the sys.path a little bit more.=
 Required on my Python 2.3 on Windows XP box.

* Enhanced MiddleKit/Tests/Test.py to summarize the results of each test at=
 the very end, like so:

RESULTS
-------
     succeeded MKBasic.mkmodel
     succeeded MKNone.mkmodel
     succeeded MKString.mkmodel
     succeeded MKDateTime.mkmodel
     succeeded MKDefaultMinMax.mkmodel
     succeeded MKTypeValueChecking.mkmodel
     succeeded MKInheritance.mkmodel
     succeeded MKInheritanceAbstract.mkmodel
     succeeded MKList.mkmodel
     succeeded MKObjRef.mkmodel
     succeeded MKObjRefReuse.mkmodel
*** FAILED *** MKDelete.mkmodel
*** FAILED *** MKDeleteMark.mkmodel
     succeeded MKMultipleStores.mkmodel
*** FAILED *** MKMultipleThreads.mkmodel
     succeeded MKModelInh1.mkmodel
     succeeded MKModelInh2.mkmodel
     succeeded MKModelInh3.mkmodel

Which brings me to my next topic which I'll post separately.


-Chuck
-- 
http://ChuckEsterbrook.com/