JPA & JDBC pitfalls, Daobab remedy

Before read - To get the point, it's good to have some JPA and JDBC experience.

For example... Let's say we have to find all pepperoni pizzas.

SQL Query:

SELECT name FROM pizza where name like '%PEPPERONI%';

JPA? Unfortunatelly won't help us...we need to write String command like this:

SELECT name FROM pizza where name like '%PEPPERONI%';

... and hide it into a few-line method:

public List<String> findPepperoni();

JPA Pitfalls:

  • incorect references - type "nsme" instead of "name" and IDE won't detect it as an error.
  • problematic refactoring - find all references and fix it one by one. IDE will not help you with this.
  • object type problem - you don't really know what type has column name. IDE won't detect an error, when column type is changed from VARCHAR to NUMBER.
  • Logic hidden into public method - method body modification is dangerous to other parts of code using it. Is the method name tell us about 'like' inside?
  • code duplications - many similar "find*" methods for many similar cases... in one place
  • strong links between entities - JPA assumes strong, hard to understand, annotation based relatons between Entities. And here is a problem when you don't need it every time... or when you don't need always lazy loading... isn't?

  • How about Daobab?

    Daobab is JPA extension library, fully compatibile with any JPA engine.

    Daobab query is a single line of code. Instantly, we see what's about:

    List<String> list=

    Daobab benefits:

  • Query visible as a Java code with 100% IDE support. Autocomplete is in use and spell problem is eliminated.
  • Safe for modification - influence to other parts of code eliminated because Query can be build in a single line, directly into main logic
  • Safe parameter types - colName() is linked to String, so only this type can be used as Query value parameter. Problem eliminated.
  • Safe return type - returned colName() is linked to String, so only this type can be returned ClassCastException eliminated.
  • Easy refactoring. When database column name is changed - just change one place: colName method.
  • DAO as trully linked with DataBase. Do not afraid of database refactoring anymore.
  • easy relations - @OneToOne,@OneToMany,Joins... was a problem before? Not anymore. Load related objects when you want, howewer you want... and skip them them whenever you want.

  • Deeper Daobab usage brings more benefits:

  • Trully ORM (DAO without id's)
  • Deadly fast queries over in-memory cache.
  • Much faster relations between entities
  • Easy projections
  • faster lazy-loading