Fantasy Soft

        今天花了两个小时的时间把users-ironpython.com Archives中8月份的Mail仔细的看了一遍，整体的感觉就是IronPython这条小蟒蛇真的太幼小了，确实需要一段很长的时间才能成长起来。当然，我们可以从它的主人Jim的Mail中体会到他抚养这条小蟒蛇所承受的压力以及他的决心。
        8月份的Mail长达3900多行，在这些Mail当中，有提问的，有but report，有对IronPython开发的建议，也有对IronPython存在意义的怀疑。现将这些Mail中的一些精华部分列举如下，当做我摸索到的IronPython第二块鳞片吧：
        1、首先一个重要的问题就是跟CPython的兼容性问题，由于IronPython使用C#实现的，那么里面使用到的自定义的module，如"Equals"和"GetHashCode",是否需要呈现给开发人员呢？同时，象list这种原来内建的对象也拥有了更多的方法，如标准的list只能使用append方法去增加list中的元素，但是IronPython增加了C#下面实现的方法：Add(object)。有开发人员针对这个问题提出了自己的疑问，而Jim所给的回答就是，因为IronPython是在一个全新的平台去实现Python，与CPython完全保持一致是不可能，即使CPython本身版本的变迁也会带来变化；
        2、IronPython现在存在的一些比较严重的Bug，一个就是在上一篇blog中提到的第四点，关于使用__main__方法抛出的<eof>异常；一个是关于类成员访问的问题，如以下代码所示：

class Buggy: 
   class_member = 'find bug' 
   def printMember(self):
       print Buggy.class_member

t = Buggy()
t.printMember()  

        这段代码存为一个.py文件，然后使用IronPythonConsole来执行，结果会抛出Unhandled Exception: IronPython.Objects.PythonAttributeError，而这段代码在CPython下是运行OK的。
        3、很多热心的开发人员都提出了需要一个subversion repository来存放IronPython的代码，大家都可以为IronPython的开发作出一份努力，同时也可以得到IronPython最新的代码。譬如上面提出的两个bug，已经有程序员找出了修改的办法，但是就是苦于没有地方提交他们的代码。而Jim给出的回应是，由于他加入了微软，为了新的工作还需要搬家，他也很诚恳的请求大家耐心等他一段时间，因为他需要做个计划。同时，他也回应了在开发上的一些怀疑：I have great confidence the resulting plan will be one that will make the developer community happy.  If the plan doesn't work for developers,then it just doesn't make sense；
        4、一位热心的开发人员开发出了一个将Visual Studio中开发的基于C#的Form代码转化为IronPython代码的工具，我还没有来得及去尝试，但是看回复的Mail，应该做得不错，有兴趣的朋友可以下载来试一下；
        5、当使用IronPythonConsole命令行的方式去执行一个.py文件的时候，会在IronPythonConsole所在的目录bin下面产生一个__main__.exe文件，但是这样产生可执行文件的方式并非是在IronPython.com首页上提到的static compilation。事实上在0.6版本中并没有真正实现这个特性。
        总结就到这里了，有兴趣的朋友，可以访问IronPython的邮件列表，以获得更详细的信息。 

       今天非常开心，因为终于将昨天一个让我很郁闷的问题解决了。事情是这样的，根据业务逻辑的要求，需要对两张数据表进行更新，为了保证数据的完整性，就需要使用transaction的概念了。如以下代码所示：

conn.setAutoCommit(false);
try 
{
    PreparedStatement insertStatement = conn.prepareStatement("INSERT INTO CUSTOM_ORDER(CUSTOMER, ORDER_LIST) VALUES(?, ?)");
    insertStatement.setString(1, customer);
    insertStatement.setString(2, orderList);
    insertStatement.execute();

    PreparedStatement updateStatement = conn.prepareStatement("UPDATE PLAYER SET ACCOUNT = ACCOUNT - ? WHERE ID = ?");
    updateStatement.setInt(1, sumPrice);
    updateStatement.setString(2, customer);
    updateStatement.execute(); 
    
    conn.commit();
} 
catch(SQLException se)
{
    conn.rollback();
}
finally
{
    conn.close();
}

        代码很简单，而且根据我以前的经验来看，这样的代码是可以保证数据完整性的，因为对数据表两个连续的更新是一个事务，当发生异常的时候，事务会回滚。然而，测试的结果出乎意料，即使第二个SQL语句执行发生了异常，第一个SQL产生的更新结果也会体现到数据表中。查阅了很多资料，都没有发现这样的代码会有什么问题，而且Java Tutorial对于事务的介绍所给出的例子跟以上代码十分的类似，讲解中也提到两个preparedStatment只有在commit方法被调用的时候，才会作用于数据库。后来我在第一个execute方法之后设置了断点，竟然发现在执行完该方法之后，CUSTOM_ORDER表中已经多了一条记录了。但是此时，我并没有想到这会跟数据库本身有关，拼命在Google上找与JDBC相关的资料。
        最后，在跟一位朋友讨论这个问题的时候，他问我：“你用的什么数据库啊？”我说是MySql，他马上很肯定的告诉我，MySql不支持事务。“不支持事务？！”我立即去查阅了MySql相关的资料^[1]，果然，MySql在4.0系列之前确实是没有支持事务的。我的朋友曾在3.x系列版本的MySql下面做了两年的开发，因此才会这样告诉我这样的结论。然而4.x系列是可以支持事务的啊，我用的是4.0.16自然也支持了，为什么还会出现这样的情况呢？
        原来，MySql的数据表分为两类，一类是传统的数据表，另一类则是支持事务的数据表。支持事务的数据表分为两种：InnoDB和BerkeleyDB。我们可以通过以下的命令确认安装的MySql Server是否支持这两种数据表：
        SHOW VARIABLES LIKE 'have_innodb';
        SHOW VARIABLES LIKE 'have_bdb';
即使MySql Server本身是支持这两种数据表，但是并不代表着创建新表的时候，新表就是属于这两种的。通常，在创建新表的时候，如果没有加以特别的说明，那么创建的新表则是传统的数据表，是不会支持事务的。因此，我的问题也就解决了，因为以上的示例代码操作的是两张没有支持事务的数据表，怎么可能去处理事务呢？
        通常我们可以通过使用如下的方式来创建支持事务的数据表：
        CREATE TABLE TABLE_NAME(FIELD1, FIELD2.... FIELDn) TYPE=INNODB;
如果原来建好的数据表，我们也可以通过ALTER TABLE命令直接去改变数据表的类型，而不需要备份数据，然后Drop表，再建立新表，再导入数据这样烦琐的步骤。如：
        ALTER TABLE TABLE_NAME TYPE=INNODB;
       
       [1] Using Transaction in MySQL