TOB - An ORM Replacement Unleashes Real Power Of Java OO Per

你完全没有理解complystill举的例子，在他的例子里面marriage这个relationship才是关键，如果你的需求只是要知道A的配偶是B，确实只要2个Class。但是如果你需要知道A和B在啥时间结得婚，然后啥时间又离了，就得需要marriage这种东西了。（ 参考 http://www.tdan.com/i021ht04.htm Figure 10: Party Relationship Subtypes）

这种基于关系/角色的设计在很多ERP软件中很常见，用Hibernate这样的ORM来处理，考虑到性能问题需要玩一些trick，不如TOB来得直观。

更加复杂的再比如这篇文章
http://www.tdan.com/i010fe04.htm
里的例子

用ORM来做就不方便，你需要考虑很多Joined Subclass, One-To-Many, Many-To-Many的设计，而且查询起来也麻烦。

That's okay. We talked many so far.


May be system logic is not really proper, I got your point now, and I'd meant system responsible logic, if this can tell more of my intention to you.


It is a Persistent Reference to Person.
spouse.o is a Person instance. Is this that different?


Okay, if you mean 4 pointers to Wheel objects as 4 fields of a Car object, by saying composition, this is plain OO, not persistency problems at all. I'd assumed you'd been talking something about persistence solutions (for PDM, ERP or other realworld apps).


I know cascading of JDO, that can guarantee you get the husband and wife directly from a got marriage object. But I didn't find promise that when you create a new marriage object, the husband/wife's spouse field will be automatically filled by JDO implementations.


I want your further comments about this, in case you changed your mind and continue replying.


TOB comes to solve a little more complex, persistency problems than your POJOs.


Then where's the time for concerning O-R mappings, JOINs, writing XML files, and DDLs?


What barrier did TOB set in your ways heading these objectives?


In fact I'm saying a source with pure Java Code is simpler than hybrid sources consists of Java, JOIN annotations, XML and DDL. Are POJOs all those you have to work on for your running persistence systems? Even with JDO?


Adios.

是的是的, TOB用来解决这个复杂程度的模型问题简直是如鱼得水.
这里的Relationship Type完全就可以通过关系类的继承树来实现, 真正发挥出OO的潜力来.
通过父关系类检索, 直接获得所有子类符合条件的结果.
如果设计时定义成@Kin集合, 则运行起来更进一步可以直接获得所有相关联的对象.

我感觉TOB还是和ORM类产品有些类似的嘛，orm把OO做到了我们编程这一步，具体的持久化还是要通过如sql这种方式来进行，我们应用中的对象和实际的数据库中的记录没有在物理存储上建立联系，而是通过逻辑来实现，TOB把oo更进了一步，做到了物理存储这一步，这样做的好处是使整个程序的各个部分更加oo，讨论这样做和ORM等的友劣不是回到OO和非OO的老问题上来了吗？但是我有个疑问，TOB本身不是一个ER数据库系统吗？怎么前面的demo中说要下H2DB等RDB呢 ？（还没运行看具体的程序和DEMO）难道他能直接操作别的RDB中记录的物理存储，估计是我理解错了，希望指点下，俺晚上回家再看看查查，thks！

我觉得很震惊的....我们国人能有这样的一个东西出来

If my requirement is to know who is whose spouse, I need just one class. With two classes I'm already able to know the attributes of marriage.

class Person {
  String name;
  Marriage marriage;
}
class Marriage {
  Person husband;
  Person wife;
  Date engageDate;
  Date weddingDate;
  Date divorceDate;
}

See? I've no problem with having a model of relationship. I just argued on how to implement it. I know this thread is hard to read now, so let me summarize this for you: "Person extends TheObject" is ugly, "Persistent<Person> person = ..." is ugly, and "A person's spouse is not a person" is ugly. But If you wanna know the full story, you'd better follow the thread and read.

I also wanna mention this again: Relational DBMS looks data in a relational aspect, while Object-oriented Programming looks data in a OO aspect. TOB tries to look data in both OO aspect and relational aspect. But unfortunately, since Java only has a OO nature, there's no way to be successful. A Relational Object Oriented Language might be able to do the job but we still don't have one (or at least I don't know one).


Thanks for sharing the document. I'll read them once I'm free.

If you are saying "tob is good for ERP" then I'm good. I'll shut up, step back, take a seat, and see what ERP guys say. Everything has its strength and weakness. If it's so good for ERP, I guess ERP guys can live with its weakness and enjoy what they can get. Both JDO and ORMs are not perfect but as long as people can get what they want they can be happy. But you know what, I won't buy the statement that "tob is good for all scenarios and in all aspects". I still don't believe he answered Yes to all my questions!

I'm not familiar with ERP. I do OLTP heavily and I don't feel that I need to persist "attributes of relationship" a lot. Yeah I do need to do some, but not a lot. In my cases "two-classes" works just fine. If I use tob then I'll have to change simple design into more complicated design, I'll have to write more classes, I'll have to treat person not as person, I'll have to be aware of the persistence, I'll have to test tob indirectly when I just wanna test my models, I'll have to loose the possibility of migration... and I get nothing useful!!

If tob is good in some cases, my suggestion is to use one of those cases as an example to show its strength. Note: the ability to make simple things complicated is not strength but weakness. In the case of person-marriage-person, I choose a solution working with POJO without any doubt.

嗯, 从运行形式上来看, TOB和ORM确实很类似, 它是借助关系数据库来做物理数据存储的, 表结构也是和持久类相对应.  不过TOB和ORM还是有一些本质区别, 最根本的应该是看待数据的出发观点.

ORM的出发点是以RDB的记录数据为中心, 内存中的持久对象是按需构造给应用程序使用的. 而后通过缓存技术来进一步提高性能.
TOB的出发点是以内存中的持久对象数据为中心, 对一个TOB持久对象来说, 要么没有Online, 要么就在内存中有一个版本的这个对象是它的权威版本, 根据TOB事务的Isolation Level不同, 多个TOB事务可能各自有这个对象的只读或者可写版本. 而只有当写了这个对象的一个事务成功提交时(根据Isolation Level判定没有一致性冲突, 并且底层物理介质成功写入), 这个事务所写版本的数据才覆盖此对象的权威版本数据.

因为这样的设计出发点的差别, 使得TOB可以获得很多ORM无法达到的优化效果, 比如持久对象拓扑图遍历, TOB自己维护的拓扑图可以直接保证是最权威的, 可以完全符合任何Isolation Level(实现最高的Serializable也是很轻易的)规则的版本; 而ORM只能通过锁死缓存实现Repeatable Read级别, 但这样又会损失数据的实时性, 一般的应用实时性还是更加重要, 所以ORM一般要通过缓存的及时标脏来实现趋近于Read Committed的级别, 而对其他级别则是根本无能为力. 但是这种方式就跟缓存扯不断关系, 无法避免缓存层面上消耗的性能. 从Benchmarks上可以看到Hot Read时, 虽然Hibernate也是把对象全部加载到内存中了, 但是性能和TOB还是有几倍到几十倍的差距, 道理就在这里.

这个出发点的差别也给TOB带来特定的负担, 比如必须自己维护对象级别的事务管理. 但是这个恰好包括在TOB要自己实现数据库的ACID特性, 从而可以称为一个真正的数据库, 而不是O-R Mapper或者Transparent Persistent Layer这个目标之内.

基于这个设计出发点的转变, 也使得TOB能够脱离RDB的一些传统的, 与OO不相适合的持久处理手法, 转而以OO的程序设计语言语义来表达持久数据模型, 所以才能够让应用程序只写Java代码, 而不用考虑非OO的DDL, ManyToMany, JOIN等等问题了.


以TOB的架构设计是不必绑定到RDB存储的, 底层物理存储在TOB架构中被抽象为SwapEngine. 非常类似虚拟内存和物理内存的关系, TOB的思想是假定对象都在内存里, 物理内存不够用时把当前没有用到的内存对象交换出去. 有一个差别是TOB的SwapEngine不仅负责处理物理存储, TOB还希望它提供额外的数据检索能力(继承并扩充TheObjectBase.Querier, 提供更多检索方法). 对TOB应用来说, 基于持久对象拓扑的检索是最直接的, 写个遍历函数里面用编程语言的语法加以比较就行了. 不过有时候还是需要一些统计性或者经过索引优化的线性检索, 这是RDB的看家本领, 也是非常成熟的技术了, 所以这样的工作TOB干脆交给底层存储来做. 就像在NTFS卷上搜索文件, 你既可以一个一个遍历匹配, 也可以让XP自动建立索引, 通过Windows的API来检索. 后一种方案既然有很成熟的技术了, 何乐而不为呢.

随同目前的TOB版本发布的第一批SwapEngine都是利用RDB的, 只不过对各家产品的差异稍作调整, 都是通过JDBC来访问. 这样做同时还有一些其他用意, 利用起RDB的检索能力是包括在内的, 整体的目的是为了保护现有投资, 这个投资不仅仅是说潜在TOB用户已经购买RDB产品的投资, 从广泛的意义上来讲, 是整个计算机产业对RDB技术和产品以及大量的外围产品的投资, 包括理论的研究和推广, 相关产品的设计,开发和维护, 设计和开发人员对SQL等相关技术的学习成本投入, 甚至包括业界对JDBC规范制定的投入等等. 这些都是巨大的价值. TOB也可以实现一个自家的SwapEngine, 支持从文件系统到磁盘分区到裸设备的存储方式 (随着TOB和其他面向对象的关系数据库系统的成熟发展壮大, 将来这个倒是也很有可能), 不过就目前的情况来看, 提供相应的开发, 维护, 分析工具, 以及和其他程序设计语言, 软件系统的接口等等工作的成本过于巨大, 不是一个新生产品的开发商所能承担得了的. 所以第一步, TOB是跑在关系数据库的物理存储上的. 但是TOB本身是自己管理对象事务的, 它运行在Serializable的Isolatioin Level的时候, 也只是要求底层的关系数据库 运行在Read Committed级别上. 这是TOB区别于ORM或者其他把关系数据库包装成OO接口的抽象层产品的标志性特征之一.

这个其实也不算超出常理, 恰好30年前提出 Entity Relation 模型的 Peter Chen(陈品山)教授, 就是华人, 只不过他是Chinese American. 很多人问他为什么他能想到这样的模型时, 他在一些作品里坦陈这和他的中华文化传承不无关系. 因为我们的文字, 不像拼音文字那样只是表音, 而是在表意, 通过意象的组合来表达新的含义. Peter说这本身就是对自然世界的建模.

过去国人在这些方面的贡献甚微, 也是因为我们的环境不好, 有了文化就是 "知产阶级", 变成半个阶级敌人, 国家公敌了, 往轻里说也是 "臭老九". 谁还敢显露本事呀, 有能力也最好装傻.

现在环境好了呀, 代表先进生产力的是国家领导者了, 这是一个很重要的转变. 中国人从来不笨, 可能更聪明的, 有时候国运不好受窝囊也没办法. 但现在不是那个时候了, 有本事可以尽管拿出来了. 现在唯一的劣势是我们这批人的收入水平还没有国外那帮人那么高, 这个也需要一个过程, 总之我们的环境在越变越好, 希望属于我们.

仅仅拿POJO模型与TOB的ORK模型进行比较有失公平, 请看下图:

看了你的测试：关于read_hot的性能，因为hibernate默认支持可及化的持久化，所以在查询前会检查所有对象的各个字段是否做了修改（通过跟快照的比较），时间消耗在这上面。只要调用sesession.setFlushMode(FlushMode.NEVER)就没有这个消耗了。

另外，hibernate的测试中：没有用到二级缓存，query cache。实际的数据库查询，这当然慢了很多节了。对于标准的jpa,为了支持高级别的隔离级别，可以使用lock,refresh来触发真正的数据库读。

另外对于TOB:
1.如果数据一部分在内存，一部分在数据库，查询是如何执行的？
2.在read commmit下的多个并发事务，tob是如何控制内存跟数据库的同步的。
在有冲突的情况下，我可想象到方法：
第一：通过事务完成时间来决定哪个对象版本是当前的版本？但是好象事务api没有得到事务完成时间的方法。
第二：由TOB来判断冲突的存在，并控制事务的执行顺序