I've recently stumbled upon an interesting blog post about when to use an ORM. I found it to be well-written and quite objective, specifically with respect to its model complexity and throughput diagram: The ORM or not ORM topic will probably never stop showing up on blogs. Some of them are more black and white, … Continue reading High Complexity and Low Throughput. Reasons for Using an ORM.
Tag: jpa
LINQ and Java
LINQ has been quite a successful, but also controversial addition to the .NET ecosystem. Many people are looking for a comparable solution in the Java world. To better understand what a comparable solution could be, let's have a look at the main problem that LINQ solves: Query languages are often declarative programming languages with many … Continue reading LINQ and Java
A Typesafety Comparison of SQL Access APIs
SQL is a very expressive and distinct language. It is one of the few declarative languages which are used by a broad audience in everyday work. As a declarative language, SQL allows to specify what we're expecting as output, not how this output should be produced. As a side-effect of this, ad-hoc record data types … Continue reading A Typesafety Comparison of SQL Access APIs
jOOQ’s Reason for Being
The below paragraphs were taken from the jOOQ preface from the manual. It is worth thinking about why you should (or should not) use jOOQ in a given project. Specifically, you might be choosing between jOOQ and JPA, jOOQ and Hibernate, or jOOQ and SLICK (in a Scala context). here's some guidance (slightly biased towards … Continue reading jOOQ’s Reason for Being
Next stop on the Annotatiomania™ Train: FetchGroups
Here's how an Annotatiomaniac™ can optimise his second-level cached JPA queries conveniently by adding yet more annotations (what else?) to his simple and plain POJO's. Remember that EJB 3.0 was about removing dependencies from javax.ejb.EJBObject, javax.ejb.EJBHome and similar interfaces? Well... check out this example: import org.apache.openjpa.persistence.*; @Entity @FetchGroups({ @FetchGroup(name="detail", attributes={ @FetchAttribute(name="publisher"), @FetchAttribute(name="articles") }), ... }) … Continue reading Next stop on the Annotatiomania™ Train: FetchGroups
Annotatiomania™, next level. JPA and JAXB combined
This is a very nice specimen of annotatiomania in the wild. When people not only confuse OO with relational, but also with XML. The "OOXMLational" model class, so to speak. Check this out: @Entity @Table(name = "Person", catalog = "TestDB", schema = "dbo") @XmlRootElement @NamedQueries({ @NamedQuery( name = "Person.findAll", query = "SELECT p FROM Person … Continue reading Annotatiomania™, next level. JPA and JAXB combined
Annotatiomania™, or why did Hibernate/JPA get so complex?
I was curious about good answers to this question on Stack Overflow: https://stackoverflow.com/questions/7332904/how-to-store-a-collection-of-dates-in-hibernate And a good answer came up, pointing at this Hibernate documentation page: http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/collections.html#collections-ofvalues Is anyone out there actually willing to mess around with gazillions of annotations on simple methods? Who ever writes this stuff: @Entity public class User { [...] public String … Continue reading Annotatiomania™, or why did Hibernate/JPA get so complex?
jOOQ makes a step forward towards JPA
With the upcoming release 1.6.4 and the implementation of #198, jOOQ will start to better integrate in "standard" J2EE architecture. While jOOQ is being developed as an alternative to JPA, it should not compete with it. This means that there are some parts in JPA which can easily co-exist with jOOQ in a J2EE application: … Continue reading jOOQ makes a step forward towards JPA