The following enhancements are now in CVS. All tests pass for MySQL on=
Windows and Linux. Postgres and MS SQL are broken, but will be fixed soon.
First, the bottom line:
1) When starting new projects with MiddleKit, I suggest these two settings=
in your model:
'AccessorStyle': 'properties',
'UseHashForClassIds': True,
2) If you run the test suite, add a line to retrieve the version of your=
database in your LocalConfig.py:
sqlVersionCommand =3D 'mysql --version'
Set to None if there is nothing available.
3) If you were using strings for date/datetime/time, you will now have to=
use Python's datetime module or egenix's mx.DateTime.
Second, the details and other minor enhancements:
*** The default for the UsePickledClassesCache setting is now false. It=
occasionally created problems for multiple developers.
*** I added an AccessorStyle setting which can be 'methods' or 'properties'.=
The default is the familiar 'methods'. If you set it to 'properties' then=
you would write code like this:
=09if email.isVerified:
=09=09pass
=09user.name =3D 'Chuck'
instead of the usual:
=09if email.isVerified():
=09=09pass
=09user.setName('Chuck')
I've tested it just a bit and it seems to be working fine.
*** I had to change MiddleObject to inherit from "object" in order to=
support properties. So it's a "new style" Python class now. I don't think=
this will hurt anything, but if you have problems, let me know.
*** I added a UseHashForClassIds setting which defaults to False. When=
False, class ids are 1, 2, 3, ... as usual. When True, class ids are hashes=
of their respective class names (think fat integers like 190295020) which=
has advantages. Basically, class ids will likely stay the same even as you=
change your MiddleKit model. For example, class ids across different=
sandboxes of your application (development, test and production) will match=
up even as you add and remove classes. On the other hand, renaming a class=
changes its id.
*** The latest MySQLdb module release is 1.2. It's "last insert id" API was=
tweaked, and it now returns instances from Python's datetime module instead=
of mx.DateTime. I made fixes for both changes. Regarding datetimes,=
MiddleKit's generated code will gladly accept whatever flavors (builtin=
and/or mx) that your system has at the time of generation. In other words,=
it's not picky.
However, I *did* remove support of using strings for date, time and=
datetime.
*** I added a print-out of system information at the end of running a test=
suite so we can more easily compare results. Example:
RESULTS
-------
succeeded MKBasic.mkmodel
succeeded MKNone.mkmodel
SYSTEM INFO
-----------
sys.version =3D 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit=
(Intel)]
sys.platform =3D win32
os.name =3D nt
sys.getwindowsversion =3D (5, 1, 2600, 2, 'Service Pack 1')
os.getcwd() =3D C:\All\echuck\Projects\WebwareHEAD\MiddleKit\Tests
dbName =3D MySQL
<cmd> mysql --version
mysql Ver 12.22 Distrib 4.0.20a, for Win95/Win98 (i32)
modules with versions:
MySQLdb, (1, 0, 0, 'final', 1),=
C:\Python23\lib\site-packages\MySQLdb\__init__.pyc
_mysql, (1, 0, 0, 'final', 1), C:\Python23\lib\site-packages\_mysql.pyd
-Chuck
|