想写一套SQL subset 来搜索和计算POJO(s)
想讨论一下这个想法，希望大家给点意见。我的初步想法是这样的：
1. 最简单的POJO，属性只用简单的数据类型，包括String, int, long, double, etc
2. 用annotation来标识字段名，而类名作为表名，比如：
class FreeOzAccount {
@SqlField("FreeOz-Name") public String name;
@SqlField("FreeOz-Post-Num") public int postNum;
@SqlField("FreeOz-Last-Login") public Date last;
}
class FreeOzPoll {
@SqlField("FreeOz-Name") public String name;
@SqlField("FreeOz-Poll-Value") public long value;
}
3. 用ANTLR来解译SQL，生成Java Code，如：
CREATE INDEX FreeOzAccountName ON FreeOzAccount ( FreeOz-Name );
CREATE INDEX FreeOzPollName ON FreeOzPoll ( FreeOz-Name );
SELECT SUM(value) FROM FreeOzAccount as a, FreeOzPoll as pWHERE a.FreeOz-Name = p.FreeOz-Name AND a.Freeoz-Last-Login > '2010-01-01';
不知道哪位同学有这方面的经验？有时间的话，看看Hibernate，或其他JPA的实现，可能会有帮助。
谢谢了。 原来做的项目中有一部分就符合你的前两部分。
我当时还没接触HIBERNATE。觉得还是挺神奇的，算是我最早接触的object mapping.
就像你说的，用annotation来标识字段名，然后用reflection实现crud。
没有任何的XML配置。比heibernate简单和轻快 又见到ORM爱好者了哈，我也很喜欢，恰好现在工作中也需要弄类似的东西，不过都是C++的。
Hinernate是经典的OR mapping方式，不过我更欣赏类似Mac SDK CoreData这样的，persistence只是一方面，object lifecycle和object graph 管理也很有意思，而且storage不必一定是SQL database. 没有那么烦， 用XML写出对象关系， 然后用code generation生成crud就ok了， 采用ORM必须需要entity 超过40个以上， 才用， 不然就是瞎掰， 为技术用技术....
这个东西我2001年就做过类似的东西， 很好用！特别是写一个小的模块或者BBS这样的系统， 特别快， 生成代码的规范依据Jive的样子....
Hinernate之前也有很多ORM的东西， 只是不是那么普遍罢了.... :lol :lol :lol :lol :lol 对Java不熟，但在.net上做过类似的东西，用的是自定义的属性“Attribute”，我的理解，应该是和Java的annotation类似吧，都是针对元数据的编程。
感觉走这种方式是比Hibernate的XML要轻量不少，但有几个问题：
1.对于简单的数据关系是很清楚，但一旦关系复杂比如出现对象引用的问题时，元数据的描述还不如XML来的直观
2.对于自己实现的框架，生命周期管理方面始终不容易做得很好。我当年是被延迟加载搞得晕头转向，不得已放弃了很多包装才解决问题。后来NHibernate出来，我们转移到NHibernate平台上，感觉人家的设计，确实要完善很多。
NHibernate提供基于元数据的配置方式，我想Hibernate向来领先NHibernate不少，应该也有把？ 你说的是JAXB？
原帖由 sliuhao 于 12-8-2010 23:12 发表 http://www.freeoz.org/ibbs/images/common/back.gif
没有那么烦， 用XML写出对象关系， 然后用code generation生成crud就ok了， 采用ORM必须需要entity 超过40个以上， 才用， 不然就是瞎掰， 为技术用技术....
这个东西我2001年就做过类似的东西， 很好用！特别是写一 ... 我的需要比较简单，否则我就直接走现有的ORM路子了。我只需要把对象全部装入，然后用SELECT之类在内存中操作。
原帖由 woodheadz 于 12-8-2010 23:30 发表 http://www.freeoz.org/ibbs/images/common/back.gif
对Java不熟，但在.net上做过类似的东西，用的是自定义的属性“Attribute”，我的理解，应该是和Java的annotation类似吧，都是针对元数据的编程。
感觉走这种方式是比Hibernate的XML要轻量不少，但有几个问题：
1.对 ... Don't reinvent wheels.
http://ar.rubyonrails.org/ or sth. like this. 原帖由 key 于 13-8-2010 10:50 发表 http://www.freeoz.org/ibbs/images/common/back.gif
我的需要比较简单，否则我就直接走现有的ORM路子了。我只需要把对象全部装入，然后用SELECT之类在内存中操作。
我当时也因为要支持内存Cache，所以也实现了简单的select， 倒也不是很麻烦。
但现在如果.net上要做类似的事，用Linq之类的很多方法都能轻易实现。Java发展了这么多年，我想肯定应该有很成熟的东西了吧？ JDO + 内存数据库 就行了
更简单，功能也更强大。 但我需要的是Java的解决方案，不是吗？
原帖由 yuba 于 13-8-2010 10:51 发表 http://www.freeoz.org/ibbs/images/common/back.gif
Don't reinvent wheels.
http://ar.rubyonrails.org/ or sth. like this.
回复 #12 key 的帖子
所以我说sth. like this啊http://www.javalobby.org/articles/activeobjects/ 用hibernate+内存数据库不就可以了 我现在的实际问题是，我不想引入一个数据库，也就是说，需要自己来实现SQL解析引擎，这可能是最大的工作量。
至于如何封装给其他人，倒是相对容易的事。
这也就是为什么我想引入ANTLR的原因。
不过我还是在比较Groovy和SQL哪一种会更直观。事实上我的目标用户是一些有最基本程序能力的人，会perl，会xml，会sql，会xpath，
但基本上不会Java。引入Groovy，我基本上不用干活，直接用就行，但毕竟是一个新的语言，会有学习曲线。但如果引入SQL，就基本上没有学习曲线了。
原帖由 yuba 于 13-8-2010 12:00 发表 http://www.freeoz.org/ibbs/images/common/back.gif
所以我说sth. like this啊
http://www.javalobby.org/articles/activeobjects/
回复 #15 key 的帖子
仔细想想有这么几种做法1. 实现一个JDBC的子集
最后的形式是driver (com.pojo.Driver)，url (jdbc:pojo://localhost/database)，username，password
好处是灵活性强，可以实现远程查询和权限控制
2. 用Ruby或Groovy实现一个DSL
用MOP实现Java风格的查询，如freeOzAccount.findByXXX()，所有查询方法都是符合convention (over configuration)的missing method
3. 重用别人的成果
比如 http://josql.sourceforge.net/ 非常感谢，估计josql就是我想要的东西了。
原帖由 yuba 于 13-8-2010 21:38 发表 http://www.freeoz.org/ibbs/images/common/back.gif
仔细想想有这么几种做法
1. 实现一个JDBC的子集
最后的形式是driver (com.pojo.Driver)，url (jdbc:pojo://localhost/database)，username，password
好处是灵活性强，可以实现远程查询和权限控制
2. 用Ruby ...
页:
[1]