java rants

Whether you start with the database or start with code, no one wants to do the other one. Certainly by the DRY principle it is a waste of time and potentially a place where you could introduce bugs into your code. Today Dave and I are releasing a command-line utility that will handle the case where you start with the database and want to use JPA to access it. There are other utilities that do this that are generally built into IDEs, however this one fills the niche for those that want to do it in a more automated fashion and don’t want to edit the actual generated code. In fact, we used a previous version of this tool at Gauntlet throughout the development process to keep our database and JPA classes in sync with one another.

Introducing… dbmapper:

Usage: com.moonspider.dbmap.GenerateConfig
  -type (-t) [String] The type to generate, either ‘jpa’ or ‘gorm’ (experimental) (jpa)
  -destinationDirectory (-d) [String] Destination directory
  -url [String] The url of the database
  -pkg (-package) [String] The target package ()
  -user (-u) [String] Database user (sa)
  -password (-p) [String] Database password ()
  -globalExtends (-extends) [String] Class for all Java classes to extend
  -globalImplements (-implements) [String] Class for all Java classes to implement
  -driver [String] Database drive class
  -extension (-ext) [String] File extension for the generated code (java)
  -hibernate [String] Generate hibernate.cfg.xml to this directory
  -jaxb [flag] Enable xml binding generation

By default, the tool has a number of rules built into it that I will call ‘best practices’ at least as far as we are concerned:

1. Tables should have a primary key column named id and it should auto increment.
2. Foreign keys should be named ${foreignTableName}_id and be specified in the database.
3. Many-to-many join tables should be named ${tableName1}_${tableName2}.

If for some reason you want to break one of these rules you will need to dig into the configuration of dbmapper. On the JPA side there are a number of conventions that it uses:

1. Class and property names are converted from _ separated to CamelCase.
2. Many-to-one and one-to-one relationships are marked as eager.
3. One-to-many and many-to-many relationships are marked as lazy.
4. Relationship collections are suffixed with List rather than making them plural.

Again, these are adjustable through a configuration file that I suggest that you never use unless absolutely necessary. The most typical use case for the configuration file is when a database identifier conflicts with an identifier used in Java or Grails. In this case you can either configure dbmapper or change your database. DBMapper is designed to work well with the dbmigrate utility and in fact I recommend you use them together for the most leverage. It is great to be able to add a new migration, execute the migration, generate new classes and see exactly the effect that your database change has on the domain model.

The default functionality is also available directly from Grails. On the command-line simply type:

grails install-plugin dbmapper

This will contact the plugin repository and install the latest dbmapper plugin directly into your Grails application. Assuming that you have configured your database in the normal fashion for Grails you can then generate domain classes directly from that connection with a single command:

grails generate-domain-classes

Assuming that is successful you will find all of your domain classes in the grails-app/domain directory and also a hibernate configuration file in your grails-app/conf/hibernate directory. You should then be able to use tasks likes generate-all to create views and controllers for each of your domain classes.

There is also experimental support for creating GORM classes instead of JPA classes, however this really is experimental at this time and I suggest that you only try it if you are interested in fixing it. GORM doesn’t seem to have the flexibility dbmapper needs quite yet.

Another feature of dbmapper is the ability to create JAXB annotations on the JPA classes so the objects can be read from and written to XML in addition to the database. The dbmapper framework itself is designed to be reasonably extensible. By adding another template you can extend it to generate mappings to other persistence frameworks.

I have reviewed these products in the past but I think they have rev’d enough times to make it worth my while to revisit them and see how far they have come. As a reminder, lets again review a couple of use cases that you might have:

1. Native Microsoft Office (any version) support
2. Latest Microsoft Office
3. Microsoft Vista
4. Games
5. IE7

Again with the ideal requirements:

1. Runs applications at full speed
2. Executes them in such a way as they appear to be native applications
3. Does not require a Window license

The simplest answer is to use Crossover Office to run applications that work with it, as when it works it satisfies the ideal requirements and then use Bootcamp when you absolutely have to have a true Windows machine. Crossover Office is now robust enough to run Outlook 2003 pretty well along with some older games like Counter Strike: Source though it doesn’t have support for the very latest software. There are cases that are in-between, for example you might not need full speed but you do need full compatibility, then either Parallels or VMWare Fusion ought to work for you, like when you want to run IE7 to view a website. If you are doing anything that requires high non-graphics speed and also high-compatibility like developing software, either VMWare or Bootcamp would be your best bet. VMWare allows you to use more than 1 processor and it out benchmarks Parallels. On the other hand, Parallels is a nicer application and its Coherence-mode (integrates Windows applications into the Mac desktop experience) is better than VMWare’s Unity mode. Neither VMWare nor Parallels run highly graphical twitch games to my satisfaction. Here is a little table to help you make your decision:

• Crossover Office 6.2
  • When it works its the best option
  • Fast, well integrated, runs some games
  • Only option that doesn’t require a Windows license
  • According to CodeWeavers, will work even better under Leopard
• Bootcamp
  • It is just Windows
  • Mac’s are really good Windows machines
• Parallels Desktop 3.o (build 5160)
  • Easier to use than VMWare Fusion
  • Coherence is very mature
  • Does not really run games well
• VMWare Fusion 1.0 (build 51348)
  • Faster than Parallels
  • Unity is OK
  • Lot’s of compatible VMWare appliances
  • Not much luck running games on it

Have any questions about the options? Since I have a license to all of them and use them all for various purposes I would be happy to answer any specific questions about the products.