- Documentation »
- Community Area »
- Old Tools Road Map
|
Old Tools Road MapNote: This page is old and does not reflect the current plans for the Hibernate toolset. We are working on a new road map. IntroductionWhile working on improving the CodeGenerator for Hibernate, I've been examining all the other tools sourrounding Hibernate - just to see what they can do now and to get some thoughts on where we are heading (or at least could be heading). This "document" lay out the current state of the tools as I see it and it also includes an description of where I (Max) would like it to go - As always, you are more than welcome to comment on this, either here, on the mailinglist or in the forum. Also feel free to correct or even add information relevant to the Hibernate tools. Current stateCurrently we got the following tools:
The following image should provide you with an overview on which role the different tools has in the generation and derivation of .hbm.xml, .java and other files. <hook src="hib_images/community/hibernatetoolscurrent.png" style="position: relative; padding-left:20%;">embed</hook> As you can see, Hibernate is actually pretty well covered in regards to supporting any kind of development process (as also described here Development Process from Hibernate doc ) Yes, from the diagram, the toolset currently allows full roundtripping. The weakest link is in the reverse engineering of existing database tables. But in fairness, that step will always require a great degree of human intervention anyway. - Gavin But there is still room for improvement :) CodeGeneratorThe codegenerator has matured greatly the last few months and weeks and is more or less capable of deriving all the java class needed for any hbm.xml file (please correct me if i'm wrong here!). Shortcomings in 2.1.2(in no particular order)
Shortcomings in older versions
Note: Do not see the number of short-comings listed here as an indication that the codegenerator does not work. It does, and is very stable and functional. The reason for the "long" list of shortcomings is primarily because I know the CodeGenerator better compared to the other tools. SchemaExport / SchemaUpdateFairly complete and stable generation of proper SQL DDL (create table ...) from hbm.xml files. Some of my co-workers are using this constantly in their buildprocess and have not heard any complaint yet :) Furthermore I have not seen any request or bugreports for this tool lately. SchemaExport is very mature and complete and I don't expect to see any big changes to the current code / functionality. It is unique in the fact that SchemaExport is integrated into and maintained as part of the core Hibernate functionality / test suite. SchemaUpdate is much less mature and may or may not be practical in real life situations. Yes - I looked for some docs on what SchemaUpdate actually does - does anyone know ? :) I can see in the sourcecode that it invokes some alter statements, but did not completely grasped how much it could "discover" correctly - Max Schema Update works just like SchemaExport, but before creating a table it checks if the table already exists, and if it does it just adds missing columns. -Chris ShortcomingsNone that I know of. I couldn't get the SchemaUpdate to work correctly with PostgreSQL using the 7.3 jdbc 3.0 drivers. I also tried the development jdbc drivers too, but SchemaUpdate doesn't detect that the tables are already created, instead it just attempts to create a table that is already there. If anyone knows how to solve this, please email me at dean.mao@ichotelsgroup.com. Thanks! -- Added by Dean Mao on Sept 26, 2003 I am also having problems with it PostgreSql 7.4 -- markmansour@yahoo.com Same here- SchemaUpdate just issues create statements for existing tables, also new tables don't get created (although the SQL in the debug statements is correct). Using PostgreSQL 7.4.3 with pg74.215.jdbc3.jar and proxool .8.3. -- Bucky Jordan, Oct. 1, 2004 I am having this problem since I upgraded from 2.1 to 2.1.6; it prints a ton of errors because it is trying to create tables that already exist. I'm using it with hsqldb 1.7.2. Whats going on? -- Dobes Vandermeer, Nov. 8, 2004 I believe the Postgresql update issue will be corrected in 2.1.7 . This issue also affects Oracle and MySQL as I've been hit by it on all of them. See JIRA Issue HB-409 and JIRA Issue HB-671 -- Patrick Burleson, Nov. 12, 2004 ReverseEngToolA newcomer to the tool set. It provides a basic mapping from JDBC to one or more hbm.xml files. The mapping contains a class per table and lists the primary key and properties. Shortcomings(in no particular order)
MapGeneratorI have very limited experience with this tool, but it seems a good starting point if you already got your java classes in place. The original concept of this tool was for something that would help users "get started" with a skeletal mapping document. In practice it has not proved very useful for actual development because the generated mapping still needs to be hand edited. The basic problem is that a .class file does not contain enough information to be able to generate a mapping (if it did, we wouldn't need the mapping metadata in the first place). Now that XDoclet gives us a way to embed metadata in the Java source, this tool should probably be considered deprecated for serious development work. (It might still be useful for something like the Eclipse plugin linked below.) - Gavin Shortcomings
Hibernate XDocLet moduleA tool that was born in Hibernate, but has now been incorporated into the xdoclet core ( http://xdoclet.sf.net ). Is pretty mature and is actively developed. Shortcomings
General shortcomings
The FutureSo, what should the future bring? Well, I would like the Hibernate tools to be so complete that each possible conversion/generation step is as complete and flexible as possible - and keep on following the "keep-it-simple" philosophy. The next sections describe some of my ideas :) MiddleGen - the next generation of ReverseEngToolI would also like to see that we utilize existing "generation"-tools out there if at all possible. One of these are MiddleGen which really looks promising. It is basically a tool that builds up a data model based on an existing JDBC database. It then provides a interactive GUI where one can provide additional information about cardinality between entities and such (note: this is also possible to do via simple ant tasks). It's main force is that it is very easy to extend via its plugin framework! And it would be great if there was an Hibernate plugin for it! If we were to build a plugin for MiddleGen we would actually have a very powerful alternative to the ReverseEngTool (primarily because MiddleGen discovers relationships defined by foreign keys and allows user customization of these relationships). Thus to avoid building something that has already been done I would suggest that we took some of the Hibernate specifics in ReverseEngTool and build an plugin for MiddleGen instead. I agree with all this. Middlegen does seem to be gaining a fair amount of mindshare and I think its undesirable for our own project to be maintaining GUI-based tools. I wonder how much work is involved in writing a MiddleGen plugin. I took a look at it, and it actually looks quite easy. One can get very far by just providing a velocity template that utilizes the existing data model build by MiddleGen - I did a basic one in 10 mins, the mapping was almost as good as our existing ReverseEngTool with regards to identitfying id's and properties - The only thing missing was the Hibernate specifics, such as which id generator to use and such. For this one needs to write a small plugin that provides that information. And here there 5-6 plugins with sourcecode that could work as inspiration. - Max I think its desirable that Hibernate integrate with existing best-of-breed open source tools like XDoclet and MiddleGen, rather than trying to build everything ourselves. This lets us concentrate on being a good O/R mapper (and do one thing well). It also helps users leverage their knowledge of existing tools when migrating to Hibernate. - Gavin MiddleGen has been discussed on the forum and developer list previously but noone seems to have "picked it up" (to bad....). In the discussion it was mentioned that the "best" way to write an Hibernate plugin, would be to have it generate .java sourcecode with XDocLet comments which then could be used to build the actual hbm.xml file. This is great, but I would suggest that we ALSO wrote an plugin that generated the hbm.xml file directly as that would allow the user to go either way. It is illustrated in the following figure: <hook src="hib_images/community/hibernatetoolsfuture.png" style="position: relative; padding-left:20%;">embed</hook> Anyone up for this challenge? (I've looked at middlegen and it should be quite easy to do ... I'm just to darn busy with the codegenerator :) There is another related tool UML2EJB which generates xdoclet-marked classes for EJB & XDoclet use from .xmi files. Eventually I will produce templates for it Codegenerator of the FutureNear future:
<class name="Foo" ... >
<meta attribute="description">JavaDoc comment for Foo</meta>
<meta attribute="base-class">AbstractPersistent</meta>
<meta attribute="generated-class">FooBase</meta>
.....
<property name="bar" type="serializable" ....>
<meta attribute="description">
JavaDoc comment for getBar()
</meta>
<meta attribute="java-type">java.lang.Object</meta>
</property>
.....
</class>
Later:
The simple version:
public void addUser( User user) {
users.add(user);
}
public void removeUser( User user) {
users.remove(user);
}
The "advanced" bi-directional version:
public void addUser( User user) {
users.add(user);
users.setGroup(this);
}
public void removeUser( User user) {
users.remove(user);
users.setGroup(null);
}
Wilder Ideas :)
|
|||||||||||||||||||||||||||||||||||||
