The second edition of Java Persistence with Hibernate is now available on the Manning Early Access Program. We have three chapters ready for you, and we'll add more chapters soon.

Some highlights of the new edition:

• Coverage of the latest JPA 2.1 specification version

• All example code available as unit tests, ready to run

• Many new illustrations, hundreds of examples

• Application design recommendations for Java EE 7

• Condensed and more focused than the previous edition, 200 pages less but more content

We will update the book as soon as Hibernate 4.3 (with JPA 2.1 support), and then later this year Hibernate 5, become available. Early access subscribers will be notified of any updates. This is a great opportunity to catch up with the latest Hibernate releases, and to learn the new features of JPA 2.1 and Java EE 7.

The example code for this early access version, based on Hibernate 4.1 and JPA 2.0, can be found here.

Talk to us on the author online forum if you have any questions.

I've picked up Wicket in Action last week and I've been reading without interrupting myself so far. So now I'm reading chapter 6 and I haven't written a single line of Wicket code. It's not the first time this happened, most of my books I've read once and never tried any of the code samples.

Last week Gavin called me and we talked about the next edition of Hibernate in Action, which actually would be the second edition of Java Persistence with Hibernate. Now that JPA2 is almost done, and the first beta release with JPA2 features of Hibernate is out, updating the text is inevitable in the near future.

What I need to decide soon is if this update is going to emphasize the tutorial aspect of the book, or if I'm going to add more reference material. I don't think that decision has much to do with the length of the book (JPwH is >900 pages). It's actually all about the code examples. Of course you can not write a 1000 page tutorial, when you pass the 200 page marker, you will have to switch from tutorial mode into reference mode.

Well, because that doesn't happen automatically, you constantly ask yourself the same question: Do readers expect code that works out-of-the-book? Are they going to write that code or copy/paste it, and then expect that it will run? Will it run within the project/product setup I've explained step-by-step up to this point?

For the first two Hibernate books I always considered the answer to that question to be: Yes, maybe the readers want to try most code examples immediately and they probably will have the book open on their desk while reading, next to the keyboard, and they will try the product you are describing in Action. That was actually what the publisher expected from an in Action series book and we had endless and exhausting discussions about it. In the end, it was a lot of work and I'm sure it's not quite perfect. At some point a tutorial approach just doesn't make sense anymore and you have to break the flow and continue with point-by-point reference material. Some readers will not be able to make that jump. The reviews of the books show that, you have a few people who haven't been able to follow the text and examples and got lost at some point. They probably expected the tutorial to continue for another 800 pages.

And here I am, asking myself if I would ever do this again and why I had so much trouble doing it before. I just realized that when I read a book, I don't try the code. I'm not a newbie and I have some Java and JEE specs/framework experience, and I think it's a waste of my time to try the Hello World example in a framework book I'm reading. I'll continue reading until I hit that barrier when it's obvious to me that I need try the code I'm reading. I'll actually not continue reading a book when all the practical details are getting in my way and I've to skip pages because they are full of trivial copy this JAR here, then edit the properties file there explanations. So I'm obviously not the target audience of my own books because they start with: This is how you create your working directory, and here is how you do that on your Windows computing machine. :)

So why can't you have both in one book? I've been paying extra attention to how other writers resolve that issue. In Wicket in Action, for example, the writers obviously do not expect the reader to stop and try the examples immediately. They do not even include the product configuration and initial setup steps in the main text and instead refer to the appendix. I'm somewhat surprised they got this past the Manning in Action guidelines, btw. ;)

I'd considered this for JPwH, moving all of the setup stuff into an appendix. Don't waste 50 pages on basic setup instructions (especially JEE vs. !JEE container) but cater to those readers who have some experience and expect to pick up new stuff quickly in a day or two, without the interruption of real world problems. As the title and subtitle are probably going to be Java Persistence with Hibernate, Second Edition, I'm not really worried about what the publisher has to say.

Still, I'm afraid we're going to have many angry newbies who expect all the setup/configuration steps in chapter 1 or 2, and if one little detail is missing, they are not going to continue reading. On the other hand, what's so bad about If you don't know how to create a directory and copy a JAR file, you need to take a break and read this appendix?

So should the next edition be more like Teach yourself Hibernate in 24 hours although your shoes have 'L' and 'R' on them or should it be The Hibernate Bible, Next Edition?

P.S. Whatever happens, the next edition of JPwH will not be 900 pages. As far as I can see, the .hbm.xml and org.hibernate.Session examples will be be removed whenever they duplicate JPA functionality, so without any other changes, that's going to be 150 pages gone already.

In the last few weeks I had to migrate a MySQL database and it turned out to be more difficult than I thought. In the past I've used the tools that ship with MySQL, such as mysqldump and its various options. For the recent migrations that was surprisingly... impossible.

The first migration was from a latin MySQL database to a UTF encoded database. By default MySQL and the JDBC driver all use latin encoding (or they derive it from the system character set), so you better make sure that your database is using UTF8 if you want, for example, Chinese users to be able to store their data. I recommend doing this on a per-table basis, which is easy if you export the schema with Hibernate - just add an extension to your dialect. Also make sure that you set characterEncoding=UTF-8 on your JDBC connection string to initialize the SQL session properly. Note that the useUnicode=true switch is not necessary for MySQL 5.x.

The problem I had was the seamframework.org production database, which was latin encoded when it was created a year ago. I've been pushing migration back because we never had any issue with it and the manual migration with mysqldump and recode turned out not to work for me (some instructions for this if you want to try).

The second migration I was looking at was a migration from MySQL to PostgreSQL, for development and testing purposes. Now, many people use mysqldump for this, then fiddle about with its many command line options and switches (make it ANSI compatible SQL damnyou!) and then close their eyes and pray when they import the dump into Postgres. Well, that didn't work in my case because mysqldump exports bit typed columns as raw binary. You can't make it to export something like true or false or anything that you can import into a Postgres boolean type. The problem here is actually that MySQL (just like the mighty Oracle) doesn't support a true boolean datatype and that Hibernate defaults to creating a bit column for a java.lang.Boolean mapping. In retrospect, Hibernate should probably not do this on MySQL for portability reasons and use a tinyint(1) mapping - on the other hand it is fine if you always stay on MySQL.

So mysqldump didn't work in both cases, I had to find another solution. I solved it with DBUnit and a simple 20 line class:

import org.dbunit.database.IDatabaseConnection;
import org.dbunit.database.DatabaseConnection;
import org.dbunit.database.QueryDataSet;
import org.dbunit.operation.DatabaseOperation;

import java.sql.Connection;
import java.sql.DriverManager;

public class Migration {

    public static final String[] TABLES = new String[]{ "FOO", "BAR", "BAZ" };

    public static void main(String[] args) throws Exception {
        System.out.println("Running Migration...");

        Class.forName("com.mysql.jdbc.Driver");
        //Class.forName("org.postgresql.Driver");

        Connection exportConnection = DriverManager.getConnection(
            "jdbc:mysql://localhost/mydb", 
            "johndoe", 
            "secret"
        );
        IDatabaseConnection exportDatabaseConnection = new DatabaseConnection(exportConnection);

        Connection importConnection = DriverManager.getConnection(
            "jdbc:mysql://localhost/mytarget?characterEncoding=UTF-8&sessionVariables=FOREIGN_KEY_CHECKS=0", 
            "johndoe", 
            "secret"
        );
        IDatabaseConnection importDatabaseConnection = new DatabaseConnection(importConnection);

        for (String table : TABLES) {
        System.out.println("Migrating table: " + table);
            QueryDataSet exportDataSet = new QueryDataSet(exportDatabaseConnection);
            exportDataSet.addTable(table, "SELECT * FROM " + table);
            DatabaseOperation.INSERT.execute(importDatabaseConnection, exportDataSet);
        }

        exportDatabaseConnection.close();
        importDatabaseConnection.close();
        System.out.println("Migration complete");

    }
}

This is the code I used to migrate from MySQL latin to MySQL UTF encoding. For the PostgreSQL migration, uncomment the driver and use a different import JDBC URL. Make sure that you disable foreign key checks for the importing SQL session as you don't know or control in which order tables and rows will be exported and imported.