本文讲解docker版jxTMS是如何解决随业务变化而需要增加数据表字段的，整个系列的文章请查看：docker版jxTMS使用指南

开发中经常会遇到随着需求的变化，需要在现有的数据表中增加字段。说起来这其实非常简单，但jxTMS的诉求是低成本快速定制，所以笔者有几个考虑：

• 直接动数据库是非常危险的行为，尤其如果是SaaS版本的jxTMS，如果允许开发者可以动数据库，这将带来巨大的安全隐患；如果制订一个审核流程由供应商来做，那所谓的快速、低成本都会成为笑谈

• 由开发者来直接操作，就大大提高了开发者的门槛和学习成本，不符合jxTMS的核心诉求：低成本快速定制

• 增加新的字段后，理论上老版本的处理逻辑其实已经发生了变化【如新增字段和原有字段间的逻辑依赖、约束等关系，不处理则可能违反了业务规则，处理就必须修改老版本的处理逻辑，而且老数据还不符合这些依赖或约束】，如果不经过完整的测试，原本工作良好的老代码就可能出现各种莫名其妙的bug，这更是笔者深恶痛绝的

所以，jxTMS提供了更好的解决办法：类表联合的继承。简单的说，就是利用面向对象的继承能力，直接在老的数据类上继承出一个子类，放入要增加的字段。jxTMS则会自动完成父子两个类所对应的数据表的关联，而这一关联，对开发者透明。

我们现在演示一下什么是类表联合的继承。

首先，打开data文件，在其中添加：

class extDemo super demoData:field ID long primaryKeyfield State string len=32
;

意思是新定义一个虚拟数据类：extDemo，其继承自demoData。并额外定义了两个属性：ID、State。由于demoData中也包含了ID属性，所以extDemo就实质上和demoData在ID属性上实现了联合，而extDemo和demoData的连接由jxTMS自动完成。

保存data文件。

然后，打开capa.py文件，修改sayHello函数：

@myModule.event('cmd', 'sayHello')
def sayHello(self, db, ctx):#创建一个刚定义的extDemo类型的数据对象jo = pyORM.create(db,'extDemo')jo.Type = "ext"#中文字符串需decodejo.Name = "测试类表联合的继承".decode('utf-8')#extDemo类型的数据对象具有State属性jo.State = "第一次测试".decode('utf-8')db.update(jo, 'Type', 'Name', 'State');

然后保存并上传capa.py，并热机刷新。

这时，可以在root控制台看到extDemo的创建【去除时间等信息后】：

数据表(extDemo)是否存在：false 
创建数据表：extDemo 
CREATE TABLE extDemo(ID bigint NOT NULL PRIMARY KEY,State VARCHAR(32) NOT NULL)

然后点击快捷栏【演示->helloWorld】，然后点击【点我】按钮。

然后我们连接到mysql中：

#在root控制台中执行
mysql -u root -p
#输入密码：123456#然后执行：	
mysql> select * from extDemo;
+------------------+--------------------------------+
| ID               | State                          |
+------------------+--------------------------------+
| 1719419712569760 | 第一次测试                       |
+------------------+--------------------------------+mysql> select ID,Type,Name from demoData;
+------------------+-----------+----------------------------+
| ID               | Type      | Name                       |
+------------------+-----------+----------------------------+
| 1719331491676285 | demo      | sayHello                   |
| 1719339552080050 | 类型甲     | xx我的12x3，78              |
| 1719419712569760 | ext       | 测试类表联合的继承            |
+------------------+-----------+----------------------------+

大家会看到，extDemo虚拟数据类中的属性，分别分散到了demoData数据表和extDemo数据表中。而两者的ID是相同的【你看到自然不是1719419712569760】，这就表明这些数据是属于同一个数据对象。为了验证这一点，我们读取一下看看：

我们修改一下capa.py文件中的sayHello函数：

@myModule.event('cmd', 'sayHello')
def sayHello(self, db, ctx):#请注意，这里的读取的虚拟数据类类名是：extDemo#用你在上面的查询中所看到的ID值来取代1719419712569760jo = orm.getByID(db.getDBConn(),'extDemo',1719419712569760)jx.log('type:{}',jo.Type)jx.log('name:{}',jo.Name)jx.log('state:{}',jo.State)

然后保存并上传capa.py，并热机刷新。

然后点击快捷栏【演示->helloWorld】，然后点击【点我】按钮。这时我们在实时日志中会看到：

type:ext
name:测试类表联合的继承
state:第一次测试

这证明，我们在python中看到的extDemo虚拟数据类，确实是由demoData数据表和extDemo数据表所组成，jxTMS也确实在读取时，自动帮我们将两表联合了起来。

而增改查各种功能，对类表联合的继承都是透明的，即继承出来的子虚拟数据类和没有经过继承的虚拟数据类完全相同，jxTMS会自动感知并在需要时自动介入完成相关的联合。

注：出于安全的考虑，jxTMS中一般的虚拟数据类都是不可删除的。所以一般都会定义一个NoUsed字段，然后通过将其设为true，然后在查询时增加对NoUsed的检测来替代删除功能

由于我们没有对demoData做任何修改，所以针对demoData的老代码自然也就不需要做任何的修改而能正常运行无误。所以我们只需要针对extDemo来开发新功能就好了，完全不会影响老功能的正常使用，等新功能完整OK了，测试也没问题了，只要取消老功能的入口而代之以新功能的入口即可。

参考资料：

jxTMS设计思想

jxTMS编程手册

下面的系列文章讲述了如何用jxTMS开发一个实用的业务功能：

如何用jxTMS开发一个功能

下面的系列文章讲述了jxTMS的一些基本开发能力：

jxTMS的HelloWorld