Schauderhaft » hibernate http://blog.schauderhaft.de Softwaredevelopment, Projectmanagement, Qualitymanagement and all things "schauderhaft" Sun, 05 Feb 2012 20:46:36 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Testing Databases with JUnit and Hibernate Part 3: Cleaning up and Further Ideas http://blog.schauderhaft.de/2011/03/27/testing-databases-with-junit-and-hibernate-part-3-cleaning-up-and-further-ideas/ http://blog.schauderhaft.de/2011/03/27/testing-databases-with-junit-and-hibernate-part-3-cleaning-up-and-further-ideas/#comments Sun, 27 Mar 2011 18:40:15 +0000 Jens Schauder http://blog.schauderhaft.de/?p=741 This is the last part in this little series about testing of database code.
In the first part I extracted the session handling for the tests into a JUnit Rule.
In the second part I introduced ObjectMothers for easy creation of instances in the database.
In this part I’ll simplify the implementation of new ObjectMothers by extracting two superclasses and I’ll finish by sketching some further ideas for further development.

Lets have a look at the SuperHeroMother

  1. public class SuperHeroMother {
  2.  private final Session session;
  3.  
  4.  private String secretIdentity = "Mr. Jones";
  5.  private String name = "Name";
  6.  private String weakness = "None";
  7.  private SuperPower power = null;
  8.  
  9.  public SuperHeroMother(Session s) {
  10.   session = s;
  11.   power = new SuperPowerMother(session).instance();
  12.  }
  13.  
  14.  public SuperHero instance() {
  15.   SuperHero hero = loadInstance();
  16.   if (hero == null) {
  17.    hero = createInstance();
  18.   }
  19.   hero.power = power;
  20.   hero.weakness = weakness;
  21.   hero.secretIdentity = secretIdentity;
  22.   session.save(hero);
  23.   return hero;
  24.  }
  25.  
  26.  private SuperHero loadInstance() {
  27.   return (SuperHero) session.createCriteria(SuperHero.class)
  28.     .add(Restrictions.eq("name", name)).uniqueResult();
  29.  
  30.  }
  31.  
  32.  private SuperHero createInstance() {
  33.   SuperHero hero = new SuperHero();
  34.   hero.name = name;
  35.   return hero;
  36.  }
  37.  
  38.  public SuperHeroMother name(String aName) {
  39.   name = aName;
  40.   return this;
  41.  }
  42.  
  43.  public SuperHeroMother secretIdentity(String aSecretIdentity) {
  44.   secretIdentity = aSecretIdentity;
  45.   return this;
  46.  }
  47.  
  48.  public SuperHeroMother power(SuperPower aPower) {
  49.   power = aPower;
  50.   return this;
  51.  }
  52.  
  53.  public SuperHeroMother weaknes(String aWeakness) {
  54.   weakness = aWeakness;
  55.   return this;
  56.  }
  57. }

There is still quite some code wich will get repeated over and over again for each ObjectMother. So lets extract some of the commonalities into a superclass ObjectMother:

  1. /** create instances of type <tt>T</tt> */
  2. public abstract class ObjectMother<T> {
  3.  private final Session session;
  4.  
  5.  public ObjectMother(Session s) {
  6.   session = s;
  7.  }
  8.  
  9.  /** returns an instance based on the configuration of this object mother */
  10.  public T instance() {
  11.   T t = loadInstance(session);
  12.   if (t == null)
  13.    t = createInstance();
  14.   configureInstance(t);
  15.   session.save(t);
  16.   return t;
  17.  }
  18.  
  19.  /**
  20.   * configure the instance <tt>t</tt> according to the configuration of this
  21.   * ObjectMother
  22.   */
  23.  abstract protected void configureInstance(T t);
  24.  
  25.  /**
  26.   * try to load an instance based on the alternate key. Returns null if no
  27.   * such instance exists
  28.   */
  29.  abstract protected T loadInstance(Session session);
  30.  
  31.  /**
  32.   * create a fresh instance with the alternate key set according to the
  33.   * configuration of this ObjectMother
  34.   */
  35.  abstract protected T createInstance();
  36. }

ObjectMother uses the Template Method Pattern in order to coordinate the provisioning of intances: try to load a matching instance from the database, if this doesn’t work, create it from scratch, configure all attributes of the instance, store it in the database and return it. The loading, creating and configuring needs to get implemented in subclasses.

For the three entities used in this series we can extract even more code from the various ObjectMothers because loading the instance from the database works always in exactly the same way. But this is only the case because we have an alternate key based on a single attribute. This will be often the case but not always, so I don’t want to tie this into the ObjectMother. Instead I’ll create another super class for this special kind of ObjectMother: SingleAlternateKeyObjectMother

  1. public abstract class SingleAlternateKeyObjectMother<T, A, S extends SingleAlternateKeyObjectMother<T, A, S>>
  2.   extends ObjectMother<T> {
  3.  
  4.  private final Class<T> objectType;
  5.  private final String alternateKeyName;
  6.  private A alternateKey;
  7.  
  8.  public SingleAlternateKeyObjectMother(Session s, Class<T> theObjectType,
  9.    A defaultAlternateKey, String theAlternateKeyName) {
  10.   super(s);
  11.   objectType = theObjectType;
  12.   alternateKeyName = theAlternateKeyName;
  13.   alternateKey(defaultAlternateKey);
  14.  }
  15.  
  16.  @SuppressWarnings("unchecked")
  17.  @Override
  18.  final protected T loadInstance(Session session) {
  19.   return (T) session.createCriteria(objectType)
  20.     .add(Restrictions.eq(alternateKeyName, getAlternateKey()))
  21.     .uniqueResult();
  22.  
  23.  }
  24.  
  25.  @SuppressWarnings("unchecked")
  26.  public S alternateKey(A theAlternateKey) {
  27.   alternateKey = theAlternateKey;
  28.   return (S) this;
  29.  }
  30.  
  31.  public A getAlternateKey() {
  32.   return alternateKey;
  33.  }
  34. }

With this a SuperHeroMother contains only a couple of extremly simple methods with hardly any code duplication left:

  1. public class SuperHeroMother extends
  2.   SingleAlternateKeyObjectMother<SuperHero, String, SuperHeroMother> {
  3.  
  4.  private String secretIdentity = "Mr. Jones";
  5.  private String weakness = "None";
  6.  private SuperPower power;
  7.  
  8.  public SuperHeroMother(Session s) {
  9.   super(s, SuperHero.class, "Name", "name");
  10.   power = new SuperPowerMother(s).instance();
  11.  }
  12.  
  13.  @Override
  14.  protected void configureInstance(SuperHero hero) {
  15.   hero.power = power;
  16.   hero.weakness = weakness;
  17.   hero.secretIdentity = secretIdentity;
  18.  }
  19.  
  20.  @Override
  21.  protected SuperHero createInstance() {
  22.   SuperHero hero = new SuperHero();
  23.   hero.name = getAlternateKey();
  24.   return hero;
  25.  }
  26.  
  27.  public SuperHeroMother secretIdentity(String aSecretIdentity) {
  28.   secretIdentity = aSecretIdentity;
  29.   return this;
  30.  }
  31.  
  32.  public SuperHeroMother power(SuperPower aPower) {
  33.   power = aPower;
  34.   return this;
  35.  }
  36.  
  37.  public SuperHeroMother weaknes(String aWeakness) {
  38.   weakness = aWeakness;
  39.   return this;
  40.  }
  41. }

Note that the three last methods are only necessary when you want to control these three attributes in your tests. Also these methods actually do suffer from code duplication, but I don’t see a way to abstract over this duplication without using lots of reflection which I don’t consider worthwhile in this case.

With this infrastructure setup there shouldn’t be a reason to leave any SQL statement untested. There are some special cases though.

As mentioned in the first part of this series you should use an in memory database for these tests. It is by orders of magnitudes faster then a normal persistent database. With an in memory database (HSQLDB) we execute about 400 tests in about 5 minutes in a current project. I consider this slow as mud for unit test standards, but compare it to 90 minutes for the same tests against an Oracle database. But sometimes you might have SQL statements that are specific for a database. For example we use analytic functions which are extremely powerfull, but not supported by HSQLDB and as far as I know by no other free in memory database. In order to test these statements and still have a fast running test suite, we further extended our session factory rule. It checks if a the test method or test class is annotated with a special annotation (@OracleTest) and also checks the SqlDialect of the HibernateConfiguration. If the annotation is present, but the SqlDialect is not an Oracle dialect it does not execute the test. Our continuos integration system (Jenkins) has two jobs for the test, one configured with an oracle database and one with a HSQLDB in memory database. The later gives a fast feedback for each check in into version control and the second runs the slow, but more complete tests.

While the stuff presented here is in my opinion extremely helpfull for unit tests of database access there are other things that need testing in the context of databases. You should especially consider tests for your ddl statements and performance tests. For tests of ddl statements I provided ideas in a former article. For performance tests the approach of ObjectMothers is at least in its current form mostly useless, because creating the large amounts of data would be way to slow. So special techniques are needed here. Maybe somebody can provide helpfull links in the comments?

]]> http://blog.schauderhaft.de/2011/03/27/testing-databases-with-junit-and-hibernate-part-3-cleaning-up-and-further-ideas/feed/ 0 Testing Databases with JUnit and Hibernate Part 2: The Mother of All Things http://blog.schauderhaft.de/2011/03/20/testing-databases-with-junit-and-hibernate-part-2-the-mother-of-all-things/ http://blog.schauderhaft.de/2011/03/20/testing-databases-with-junit-and-hibernate-part-2-the-mother-of-all-things/#comments Sun, 20 Mar 2011 09:55:47 +0000 Jens Schauder http://blog.schauderhaft.de/?p=735 In the first part of this little series I showed a simple test based on a simple data model. As we saw the code for the test wasn’t simple at all, but quite ugly. We started to fix that by moving out all the SessionFactory and Session handling stuff out into a Rule. Leaving us with test code like this:

  1. public class SuperHeroRepository3Test {
  2.  
  3.  @Rule
  4.  public final SessionFactoryRule sf = new SessionFactoryRule();
  5.  
  6.  @Test
  7.  public void returnsHerosWithMatchingType() {
  8.   Session session = sf.getSession();
  9.  
  10.   SuperPowerType powerType = createSuperPowerType();
  11.   session.save(powerType);
  12.  
  13.   SuperPower superpower = createSuperPower(powerType);
  14.   session.save(superpower);
  15.  
  16.   SuperHero hero = createSuperHero(superpower);
  17.   session.save(hero);
  18.  
  19.   sf.commit();
  20.  
  21.   SuperHeroRepository heroRepository = new SuperHeroRepository(session);
  22.   List<SuperHero> heroes = heroRepository.loadBy(superpower);
  23.  
  24.   assertNotNull(heroes);
  25.   assertEquals(1, heroes.size());
  26.  }
  27.  
  28.  private SuperHero createSuperHero(SuperPower superpower) {
  29.   SuperHero hero = new SuperHero();
  30.   hero.name = "Name";
  31.   hero.power = superpower;
  32.   hero.weakness = "None";
  33.   hero.secretIdentity = "Mr. Jones";
  34.   return hero;
  35.  }
  36.  
  37.  private SuperPower createSuperPower(SuperPowerType powerType) {
  38.   SuperPower superpower = new SuperPower();
  39.   superpower.name = "SuperPower";
  40.   superpower.description = "Description";
  41.   superpower.type = powerType;
  42.   return superpower;
  43.  }
  44.  
  45.  private SuperPowerType createSuperPowerType() {
  46.   SuperPowerType powerType = new SuperPowerType();
  47.   powerType.name = "TheType";
  48.   powerType.description = "12345678901234567890aDescription";
  49.   return powerType;
  50.  }
  51. }

Since we won’t be satisfied with a single test we’ll wan’t to reuse the createXXX methods. The starting idea for how to do this comes from Martin Fowler. He describes ObjectMothers as objects wich give birth to complex objects needed for testing. This is exactly the information we are in. So the createXXX Methods should go to ObjectMothers. As you can see in the current version of the test, there are two things an ObjectMother must do:

  • create Instances of a class that have all attributes filled in a way that satisfies the constraints present in the database.
  • store them in the hibernate session.

So here is a very simple version of such an ObjectMother:

  1. public class SuperPowerTypeMother {
  2.  
  3.  private final Session session;
  4.  
  5.  public SuperPowerTypeMother(Session s) {
  6.   session = s;
  7.  }
  8.  
  9.  public SuperPowerType instance() {
  10.   SuperPowerType powerType = new SuperPowerType();
  11.   powerType.name = "TheType";
  12.   powerType.description = "12345678901234567890aDescription";
  13.   session.save(powerType);
  14.   return powerType;
  15.  }
  16. }

This gets used by the ObjectMother for SuperPowers:

  1. public class SuperPowerMother {
  2.  
  3.  private final Session session;
  4.  
  5.  public SuperPowerMother(Session s) {
  6.   session = s;
  7.  }
  8.  
  9.  public SuperPower instance() {
  10.   SuperPower superpower = new SuperPower();
  11.   superpower.name = "SuperPower";
  12.   superpower.description = "Description";
  13.   superpower.type = new SuperPowerTypeMother(session).instance();
  14.   session.save(superpower);
  15.   return superpower;
  16.  }
  17.  
  18. }

Finally add a similar SuperHeroMother and our test looks like this:

  1. public class SuperHeroRepository4Test {
  2.  
  3.  @Rule
  4.  public final SessionFactoryRule sf = new SessionFactoryRule();
  5.  
  6.  @Test
  7.  public void returnsHerosWithMatchingType() {
  8.   SuperHero hero = new SuperHeroMother(sf.getSession()).instance();
  9.  
  10.   sf.commit();
  11.  
  12.   SuperHeroRepository heroRepository = new SuperHeroRepository(
  13.     sf.getSession());
  14.   List<SuperHero> heroes = heroRepository.loadBy(hero.power);
  15.  
  16.   assertNotNull(heroes);
  17.   assertEquals(1, heroes.size());
  18.  }
  19. }

This is nice. Short and concentrated on what we want to test. Only the session hints at the presence of the database. Also when our entities get new attributes we have a single place to set a default value for that attribute for all our tests. All thats left in the test for creating a SuperHero is a one liner like this:

  1. SuperHero hero = new SuperHeroMother(sf.getSession()).instance();

So are we done? No, because the ObjectMothers have two serious problems:

  • they create new entities every time, which will result in unique constraint violations once you deal with more then one SuperHero
  • they set the attributes in the same way every time, but sooner or later you want a hero with a special SuperPower, so we want to specify some attributes we are interested in without worrying about the others.

In order to solve the first problem mothers must look in the database if an instance as the one requested is already present. For this the alternate key of the entity is used, and only if a select with this alternate key doesn’t return an entity a new one is created. Note that since each entity gets stored in the session before it leaves the mother each such lookup select causes a flush of the session and therefore sees previously created entities.

In order to set attributes of the entities a builder pattern is used. The mothers have a method named after the attribute, taking an attribute value, and returning the mother instance.

So the SuperHeroObjectMother now looks like this.

  1. public class SuperHeroMother {
  2.  private final Session session;
  3.  
  4.  private String secretIdentity = "Mr. Jones";
  5.  private String name = "Name";
  6.  private String weakness = "None";
  7.  private SuperPower power = null;
  8.  
  9.  public SuperHeroMother(Session s) {
  10.   session = s;
  11.   power = new SuperPowerMother(session).instance();
  12.  }
  13.  
  14.  public SuperHero instance() {
  15.   SuperHero hero = loadInstance();
  16.   if (hero == null) {
  17.    hero = createInstance();
  18.   }
  19.   hero.power = power;
  20.   hero.weakness = weakness;
  21.   hero.secretIdentity = secretIdentity;
  22.   session.save(hero);
  23.   return hero;
  24.  }
  25.  
  26.  private SuperHero loadInstance() {
  27.   return (SuperHero) session.createCriteria(SuperHero.class)
  28.     .add(Restrictions.eq("name", name)).uniqueResult();
  29.  
  30.  }
  31.  
  32.  private SuperHero createInstance() {
  33.   SuperHero hero = new SuperHero();
  34.   hero.name = name;
  35.   return hero;
  36.  }
  37.  
  38.  public SuperHeroMother name(String aName) {
  39.   name = aName;
  40.   return this;
  41.  }
  42.  
  43.  public SuperHeroMother secretIdentity(String aSecretIdentity) {
  44.   secretIdentity = aSecretIdentity;
  45.   return this;
  46.  }
  47.  
  48.  public SuperHeroMother power(SuperPower aPower) {
  49.   power = aPower;
  50.   return this;
  51.  }
  52.  
  53.  public SuperHeroMother weaknes(String aWeakness) {
  54.   weakness = aWeakness;
  55.   return this;
  56.  }
  57. }

Using such an object mother is extremely easy: create a mother instance, set the attributes you are interested in and call instance().

But writing a Mother is a little tedious and if done as shown above involves a lot of code duplication. So in the next part of the series we’ll do some refactoring in order to remove at least some of the code duplication.

]]> http://blog.schauderhaft.de/2011/03/20/testing-databases-with-junit-and-hibernate-part-2-the-mother-of-all-things/feed/ 2 Testing Databases with JUnit and Hibernate Part 1: One to Rule them http://blog.schauderhaft.de/2011/03/13/testing-databases-with-junit-and-hibernate-part-1-one-to-rule-them/ http://blog.schauderhaft.de/2011/03/13/testing-databases-with-junit-and-hibernate-part-1-one-to-rule-them/#comments Sun, 13 Mar 2011 21:01:25 +0000 Jens Schauder http://blog.schauderhaft.de/?p=730 Databases are an extremely important part of almost every enterprise application. Yet there is very little support for testing your database, which results in very little tests coverage of database related code out in the wild. In a desperate attempt to change that at least a little the article series starting with this article will describe some of the problems and possible partial solutions based on Hibernate and JUnit.
As an example I use the following little set of Hibernate entity classes and the database schema Hibernate will create from it:

  1. @Entity
  2. public class SuperHero extends AbstractEntity {
  3.  
  4.  @NotEmpty
  5.  @Column(unique = true)
  6.  public String name;
  7.  
  8.  @ManyToOne
  9.  @NotNull
  10.  public SuperPower power;
  11.  
  12.  @NotEmpty
  13.  public String weakness;
  14.  
  15.  @NotEmpty
  16.  public String secretIdentity;
  17. }
  1. @Entity
  2. public class SuperPower extends AbstractEntity {
  3.  
  4.  @NotEmpty
  5.  @Column(unique = true)
  6.  public String name;
  7.  
  8.  @NotEmpty
  9.  public String description;
  10.  
  11.  @NotNull
  12.  @ManyToOne
  13.  public SuperPowerType type;
  14. }
  1. @Entity
  2. public class SuperPowerType extends AbstractEntity {
  3.  
  4.  @NotEmpty
  5.  @Column(unique = true)
  6.  public String name;
  7.  
  8.  @NotNull
  9.  @Length(min = 30)
  10.  public String description;
  11. }

As you can see (and if you don’t I tell you) a SuperHero references a SuperPower and a SuperPower references a SuperPowerType. All have some mandatory attributes.
All three entities have a common supertype providing id and version.

  1. @MappedSuperclass
  2. public class AbstractEntity {
  3.  
  4.  @SuppressWarnings("unused")
  5.  @Id
  6.  @GeneratedValue
  7.  public Long id;
  8.  @SuppressWarnings("unused")
  9.  @Version
  10.  private Long version;
  11. }

For brevity I skipped on getters and setters.

Finally there is a SuperHeroRepository which I want to test. It has a single method returning a SuperHero based on the a SuperPower
A simple test for the SuperHeroRepository might work like this:

Create a SuperHero and make sure I can retrieve it again using the SuperHeroRepository.

Easy, isn’t it? Well … lets see what you really have to do

  • create an empty database
  • create a SuperPowerType, making sure you have all the mandatory fields filled
  • create a SuperPower of that type, making sure you have all the mandatory fields filled
  • create a SuperHero, making sure you have all the mandatory fields filled
  • use the repository to retrieve SuperHeros
  • assert you got the expected result.

So we have to fill all the mandatory fields and provide a SuperPowerType (again with all the mandatory fields) although nothing in the test is concerned with SuperPowerTypes. If you still don’t believe this results in ugly code have a look at this naive implementation.

  1. public class SuperHeroRepository1Test {
  2.  private SessionFactory sessionFactory;
  3.  private Session session = null;
  4.  
  5.  @Before
  6.  public void before() {
  7.   // setup the session factory
  8.   AnnotationConfiguration configuration = new AnnotationConfiguration();
  9.   configuration.addAnnotatedClass(SuperHero.class)
  10.     .addAnnotatedClass(SuperPower.class)
  11.     .addAnnotatedClass(SuperPowerType.class);
  12.   configuration.setProperty("hibernate.dialect",
  13.     "org.hibernate.dialect.H2Dialect");
  14.   configuration.setProperty("hibernate.connection.driver_class",
  15.     "org.h2.Driver");
  16.   configuration.setProperty("hibernate.connection.url", "jdbc:h2:mem");
  17.   configuration.setProperty("hibernate.hbm2ddl.auto", "create");
  18.  
  19.   sessionFactory = configuration.buildSessionFactory();
  20.   session = sessionFactory.openSession();
  21.  }
  22.  
  23.  @Test
  24.  public void returnsHerosWithMatchingType() {
  25.  
  26.   // create the objects needed for testing
  27.   SuperPowerType powerType = new SuperPowerType();
  28.   powerType.name = "TheType";
  29.   powerType.description = "12345678901234567890aDescription";
  30.  
  31.   SuperPower superpower = new SuperPower();
  32.   superpower.name = "SuperPower";
  33.   superpower.description = "Description";
  34.   superpower.type = powerType;
  35.  
  36.   SuperHero hero = new SuperHero();
  37.   hero.name = "Name";
  38.   hero.power = superpower;
  39.   hero.weakness = "None";
  40.   hero.secretIdentity = "Mr. Jones";
  41.  
  42.   // storing the objects for the test in the database
  43.   session.save(powerType);
  44.   session.save(superpower);
  45.   session.save(hero);
  46.  
  47.   SuperHeroRepository heroRepository = new SuperHeroRepository(session);
  48.   List<SuperHero> heroes = heroRepository.loadBy(superpower);
  49.   assertNotNull(heroes);
  50.   assertEquals(1, heroes.size());
  51.  }
  52.  
  53.  @After
  54.  public void after() {
  55.   session.close();
  56.   sessionFactory.close();
  57.  }
  58. }

There is really only one positive thing I can say about this test: it uses H2 in In-Memory mode so it is reasonable fast. There is the first lesson: *Use an in memory database for testing if possible. It’s easily 100*faster then a disc based database*

So obviously we want to refactor this monster, which might after some method extracting result into something like this:

  1. public class SuperHeroRepository2Test {
  2.  
  3.  private SessionFactory sessionFactory;
  4.  private Session session;
  5.  
  6.  @Before
  7.  public void before() {
  8.   sessionFactory = createSessionFactory();
  9.   session = sessionFactory.openSession();
  10.   Transaction transaction = session.beginTransaction();
  11.  }
  12.  
  13.  @Test
  14.  public void returnsHerosWithMatchingType() {
  15.  
  16.   SuperPowerType powerType = createSuperPowerType();
  17.   session.save(powerType);
  18.  
  19.   SuperPower superpower = createSuperPower(powerType);
  20.   session.save(superpower);
  21.  
  22.   SuperHero hero = createSuperHero(superpower);
  23.   session.save(hero);
  24.  
  25.   SuperHeroRepository heroRepository = new SuperHeroRepository(session);
  26.   List<SuperHero> heroes = heroRepository.loadBy(superpower);
  27.  
  28.   assertNotNull(heroes);
  29.   assertEquals(1, heroes.size());
  30.  }
  31.  
  32.  private SessionFactory createSessionFactory() {
  33.   AnnotationConfiguration configuration = new AnnotationConfiguration();
  34.   configuration.addAnnotatedClass(SuperHero.class)
  35.     .addAnnotatedClass(SuperPower.class)
  36.     .addAnnotatedClass(SuperPowerType.class);
  37.   configuration.setProperty("hibernate.dialect",
  38.     "org.hibernate.dialect.H2Dialect");
  39.   configuration.setProperty("hibernate.connection.driver_class",
  40.     "org.h2.Driver");
  41.   configuration.setProperty("hibernate.connection.url", "jdbc:h2:mem");
  42.   configuration.setProperty("hibernate.hbm2ddl.auto", "create");
  43.  
  44.   SessionFactory sessionFactory = configuration.buildSessionFactory();
  45.   return sessionFactory;
  46.  }
  47.  
  48.  private SuperHero createSuperHero(SuperPower superpower) {
  49.   SuperHero hero = new SuperHero();
  50.   hero.name = "Name";
  51.   hero.power = superpower;
  52.   hero.weakness = "None";
  53.   hero.secretIdentity = "Mr. Jones";
  54.   return hero;
  55.  }
  56.  
  57.  private SuperPower createSuperPower(SuperPowerType powerType) {
  58.   SuperPower superpower = new SuperPower();
  59.   superpower.name = "SuperPower";
  60.   superpower.description = "Description";
  61.   superpower.type = powerType;
  62.   return superpower;
  63.  }
  64.  
  65.  private SuperPowerType createSuperPowerType() {
  66.   SuperPowerType powerType = new SuperPowerType();
  67.   powerType.name = "TheType";
  68.   powerType.description = "12345678901234567890aDescription";
  69.   return powerType;
  70.  }
  71. }

This would be ok, if this would be the only test of this kind. But other similar test need the SessionFactory as well so I will move all the SessionFactory, Session and Transaction stuff into a Rule

  1. public class SessionFactoryRule implements MethodRule {
  2.  private SessionFactory sessionFactory;
  3.  private Transaction transaction;
  4.  private Session session;
  5.  
  6.  @Override
  7.  public Statement apply(final Statement statement, FrameworkMethod method,
  8.    Object test) {
  9.   return new Statement() {
  10.  
  11.    @Override
  12.    public void evaluate() throws Throwable {
  13.     sessionFactory = createSessionFactory();
  14.     createSession();
  15.     beginTransaction();
  16.     try {
  17.      statement.evaluate();
  18.     } finally {
  19.      shutdown();
  20.     }
  21.    }
  22.  
  23.   };
  24.  }
  25.  
  26.  private void shutdown() {
  27.   try {
  28.    try {
  29.     try {
  30.      transaction.rollback();
  31.     } catch (Exception ex) {
  32.      ex.printStackTrace();
  33.     }
  34.     session.close();
  35.    } catch (Exception ex) {
  36.     ex.printStackTrace();
  37.    }
  38.    sessionFactory.close();
  39.   } catch (Exception ex) {
  40.    ex.printStackTrace();
  41.   }
  42.  }
  43.  
  44.  private SessionFactory createSessionFactory() {
  45.   AnnotationConfiguration configuration = new AnnotationConfiguration();
  46.   configuration.addAnnotatedClass(SuperHero.class)
  47.     .addAnnotatedClass(SuperPower.class)
  48.     .addAnnotatedClass(SuperPowerType.class);
  49.   configuration.setProperty("hibernate.dialect",
  50.     "org.hibernate.dialect.H2Dialect");
  51.   configuration.setProperty("hibernate.connection.driver_class",
  52.     "org.h2.Driver");
  53.   configuration.setProperty("hibernate.connection.url", "jdbc:h2:mem");
  54.   configuration.setProperty("hibernate.hbm2ddl.auto", "create");
  55.  
  56.   SessionFactory sessionFactory = configuration.buildSessionFactory();
  57.   return sessionFactory;
  58.  }
  59.  
  60.  public Session createSession() {
  61.   session = sessionFactory.openSession();
  62.   return session;
  63.  }
  64.  
  65.  public void commit() {
  66.   transaction.commit();
  67.  }
  68.  
  69.  public void beginTransaction() {
  70.   transaction = session.beginTransaction();
  71.  }
  72.  
  73.  public Session getSession() {
  74.   return session;
  75.  }
  76. }

Which leaves the test in a somewhat acceptable state.

  1. public class SuperHeroRepository3Test {
  2.  
  3.  @Rule
  4.  public final SessionFactoryRule sf = new SessionFactoryRule();
  5.  
  6.  @Test
  7.  public void returnsHerosWithMatchingType() {
  8.   Session session = sf.getSession();
  9.  
  10.   SuperPowerType powerType = createSuperPowerType();
  11.   session.save(powerType);
  12.  
  13.   SuperPower superpower = createSuperPower(powerType);
  14.   session.save(superpower);
  15.  
  16.   SuperHero hero = createSuperHero(superpower);
  17.   session.save(hero);
  18.  
  19.   sf.commit();
  20.  
  21.   SuperHeroRepository heroRepository = new SuperHeroRepository(session);
  22.   List<SuperHero> heroes = heroRepository.loadBy(superpower);
  23.  
  24.   assertNotNull(heroes);
  25.   assertEquals(1, heroes.size());
  26.  }
  27.  
  28.         // … private methods more or less as before
  29. }

All the SessionFactory creation is now moved out into a Rule and is therefore perfectly reusable. You now can change the way you create your SessionFactory at a single point for all tests in need of a database. This is nice and it shall be enough for today. Next week we’ll take care of our SuperHero and her dependencies.

]]> http://blog.schauderhaft.de/2011/03/13/testing-databases-with-junit-and-hibernate-part-1-one-to-rule-them/feed/ 9 An Analysis of NonUniqueObjectException and LazyInitializationException in Hibernate http://blog.schauderhaft.de/2010/07/11/an-analysis-of-nonuniqueobjectexception-and-lazyinitializationexception-in-hibernate/ http://blog.schauderhaft.de/2010/07/11/an-analysis-of-nonuniqueobjectexception-and-lazyinitializationexception-in-hibernate/#comments Sun, 11 Jul 2010 19:25:19 +0000 Jens Schauder http://blog.schauderhaft.de/?p=529 I consider Hibernate a great and useful tool. But it has some mean Exceptions lurking in the darker corners. Today I’d like to explore the ones from the title in a little more detail, including different approaches on how to avoid them.

Let’s start with the well known LazyInitializationException. When you search for this one in the Internet you end up with scenarios like this one:

You load A, close the session you  used and try to access a property of A which gets loaded lazily resulting in a LazyInitializationException. That one is well described, including strategies to avoid it, which basically consist of not closing the session to early.

But there are more hideous scenarios. Assume the classes Mom, Dad and Kid are mapped as one would expect, with references from Mom and Dad to Kid. Now consider the following piece of code:

  1. Session session = openSession();
  2. session.beginTransaction();
  3.  
  4. Mom mom = (Mom) session.load(Mom.class, momId);
  5. Kid momsKid = mom.getKid();
  6.  
  7. // dad comes by
  8. Dad dad = (Dad) session.load(Dad.class, dadId);
  9. Kid dadsKid = dad.getKid();
  10.  
  11. // and leaves
  12. session.evict(dad);
  13.  
  14. // alas he has taken kido with him
  15. momsKid.getName();

Depending on your exact Mapping you might get a LazyInitializationException in the last line, although the session is still open. The problem here is that when dad got evicted the kid got evicted as well. And since Mom has a reference to the exact same object, that object isn’t attached to any session anymore. In order to see this effect you’ll have to use mappings like this:

@ManyToOne(fetch = LAZY, cascade = CascadeType.ALL)
  1.     @Cascade(org.hibernate.annotations.CascadeType.ALL)
  2.     private Kid kid;

The NonUniqueObjectException gets caused by what could be considered the reverse process. Examine the following piece of code:

  1.         // Dad left for another woman, I mean Session
  2.         Dad dad = loadDad();
  3.  
  4.         Session session = openSession();
  5.         session.beginTransaction();
  6.  
  7.         Mom mom = (Mom) session.load(Mom.class, momId);
  8.         System.out.println(mom.getKid().getName());
  9.  
  10.         // Now dad wants to move back in
  11.         session.saveOrUpdate(dad);

The first method call loads a Dad object including Kid from a different session. Then from the ‘main’ session Mom gets loaded including kid. When we attach the Dad object to the session it tries to attach its version of the Kid as well, which collides with the Kid already present in the session.

So how can we avoid these kind of problem? I see several options:

  • Don’t use Cascade. Of course this means much more effort on your side in many cases, since you have to carefully track what you need to attach or evict from a session.
  • Don’t use evict and don’t reattach existing instances to sessions. I guess this should work in many cases. But I have seen cases where this approach would have caused a large overhead, because reloading complex object graphs.
  • Carefully design your cascading boundaries. A look at the Aggregate Root from DDD might help here. An Aggregate Root is a single class which works as a gate keeper (did anybody say facade) to a cluster of classes related to the Aggregate Root. When all the Hibernate related actions go against that Aggregate Root, and cascade from there to the content and only the content of the Aggregate Root you should be safe. All entities outside an Aggregate Root have to use the Aggregate Root or Repositories to gain access. This needs some bookkeeping. But when you do it properly it might actually improve the over all design of your code. Please note that all this is a thought experiment on my side, and I can’t promise that it actually works as intended, but I think it should.

If you want the complete source code for the example, you can download this source.zip file.

]]> http://blog.schauderhaft.de/2010/07/11/an-analysis-of-nonuniqueobjectexception-and-lazyinitializationexception-in-hibernate/feed/ 0 Hibernate has Problems, but where is the Alternative? http://blog.schauderhaft.de/2009/10/18/hibernate-problems-alternative/ http://blog.schauderhaft.de/2009/10/18/hibernate-problems-alternative/#comments Sun, 18 Oct 2009 17:30:55 +0000 Jens Schauder http://blog.schauderhaft.de/?p=294 875413_47541979

Scale

In a late blog post Stephan Schmidt vents his problems with hibernate and declares “ORMs are a thing of the past”

I agree to some extend:
- The SQL generated by Hibernate by default is horrible. Huge joins, with hundreds of columns, many unneeded.
- Annotations feel like dirt in your code, and maintaining XML mappings is just painful.
- LazyInitializationExceptions are a pain in the a.. neck.

But does that justify the conclusion, that ORMs will go away in the near future? I don’t think so. Of course my perspective is biased, but in the applications I build I deal typically with 200-500 tables. Just typing the basic CRUD Statement, and wrapping them into usable objects is a pain, and a lot of work, which I gladly will hand over to an ORM.

Tracking changes in objects is another task, I gladly handover to an ORM.

Even writing annotations, while being far from perfect is better then most alternatives I know.

Implementing my own caching logic? No thanx. The ORM can do that pretty well.

I think the crucial point lies in Stephans last paragraph, where he sketches some ideas for alternatives. ORMs aren’t bad in themselves. They are just difficult to get right. Hibernate did a great job. It is the first one to get wide spread usage. And most points mentioned above are a weakness in Hibernate (or JPA) or possibly Java. So my claim is: ORMs aren’t dead, they aren’t even grown up.

So what properties might a grown up ORM have?

  • Usage of persistence independent annotations: The problem with annotations is: they don’t belong in the business domain, where your classes live. They are part of the persistence layer, and should stay there. But when you look at the JPA annotations you’ll find a lot that is pretty usefull in GUI context as well. For example the length of a field isn’t only important for the database but for the GUI as well. Same for validations. So I’d think, in a couple years from now we’ll have annotations (or other language features), that let us specify features of properties and references, which truely live in the domain world. And the ORMs will just utilize that information for 90% of their needs
  • When the references will have more information attached to them. E.g. if it is just a association, or an aggregation, or if the M in an 1:M relation is ‘big’. And ORMs will use that to optimize there SQL.
  • The management of Sessions will move toward a declarative style, just as transactions did in the last decade.
  • RDBMS vendors will finally realize the power of ORMs, and will provide more efficient protocols for the ORMs to communicate with.
  • ORMs will monitor how they are used for a certain application, and will use that information to improve the SQL used.

But as so often, the most important change will be a people change: People will finally let databases drop into the background where they belong, and manage the schema through the ORM. I always wonder “Why?” when I hear people describe how the build a database first, and then map classes to the tables. That is the wrong way around: Build a strong domain model first. Let the ORM create a database schema for you from that. And then get someone with strong database knowledge involved to tweak it where necessary. This is when you start seriously gaining something for your struggle with the ORM. Most importantly: you get strong support for database refactorings.

If you want to read more about the whole ORM discussion, you might be interested in this article by Debasish Ghosh.

]]> http://blog.schauderhaft.de/2009/10/18/hibernate-problems-alternative/feed/ 13