Depending on whether the transaction encloses the loop, batching typically already happens in your case. JPA will collect all your updates in its L1 cache, and typically write that all to the DB in a batch when the transaction commits. This is not really that different with batching in JDBC, where every batch-item you add … Read more
JPA is just an API (hence Java Persistence API) that requires an implementation to use. An analogy would be using JDBC. JDBC is an API for accessing databases, but you need an implementation (a driver jar file) to be able to connect to a database. On its own, without a driver, you cannot do anything … Read more
Put the following properties in your persistence.xml: <property name=”eclipselink.logging.level.sql” value=”FINE”/> <property name=”eclipselink.logging.parameters” value=”true”/> The latter is helpful, so that the values of the parameter are shown. An alternative is using log4jdbc or log4jdbc-remix.
Based on @scottb solution I made this, tested against hibernate 4.3: (no hibernate classes, should run on JPA just fine) Interface enum must implement: public interface PersistableEnum<T> { public T getValue(); } Base abstract converter: @Converter public abstract class AbstractEnumConverter<T extends Enum<T> & PersistableEnum<E>, E> implements AttributeConverter<T, E> { private final Class<T> clazz; public AbstractEnumConverter(Class<T> … Read more
Join on one-to-many relation in JPQL looks as follows: select b.fname, b.lname from Users b JOIN b.groups c where c.groupName = :groupName When several properties are specified in select clause, result is returned as Object[]: Object[] temp = (Object[]) em.createNamedQuery(“…”) .setParameter(“groupName”, groupName) .getSingleResult(); String fname = (String) temp[0]; String lname = (String) temp[1]; By the … Read more
Thanks Stéphane – the edit at the end of your question helped me “fix” the same problem. For anyone else who hits this as well – here is an expanded answer. This is what you need to “fix” things in your pom (until Eclipse fix things properly): <!– See https://stackoverflow.com/q/45870753 –> <dependency> <groupId>org.eclipse.persistence</groupId> <artifactId>eclipselink</artifactId> <version>2.7.0</version> … Read more
In your first example, the changes to the data are reflected in database after encountering flush, but it is still in transaction. But in second example, you are committing transaction immediately. Therefore the changes are made into the database & transaction also ends there. Sometimes, flush may be useful to persist the data in between … Read more
I had this issue, and solved. This was due to the WHERE clause contains String value instead of integer value.
This behavior is correct, otherwise if you change object one and object two with different values you will have problems when persisting them. What is happening is the call to load object two updates the entity loaded in the first call. They must point to the same object since they ARE the same object. This … Read more
I always go STRING. Speed is rarely the most important issue – readability and maintainability are more important. I use STRING because it’s a lot easier to manually inspect rows from the database, but more importantly, I can do two things, without touching the database, the ORDINAL can’t handle: I can change the order of … Read more