Develop Reference

How to replace deprecated MultipleHiLoPerTableGenerator with TableGenerator in Hibernate

I use hibernate in an application with spring boot 1.4.0.RELEASE.
The Entity for the index looks something along the lines of:
#Entity(name = "SearchableTariffItem")
#Indexed
public class SearchableTariffItem {
public static final String ZIFFER_ANALYZER_NAME = "ZIFFER_ANALYZER";
#GeneratedValue(strategy = GenerationType.TABLE)
#Id
private Long id;
...
}
I now get the following warning when I save the entity for the first time:
2016-08-26 15:08:32.501 WARN 8476 — [apr-8080-exec-6] org.hibernate.orm.deprecation : HHH90000015: Found use of deprecated [org.hibernate.id.MultipleHiLoPerTableGenerator] table-based id generator; use org.hibernate.id.enhanced.TableGenerator instead. See Hibernate Domain Model Mapping Guide for details.
Unfortunately I don't know where I can configure my application (preferably in a the application.yml) to use the TableGenerator class.
I use the following dependency:
Hibernate core 5.0.9.Final
Hibernate search ORM 5.5.1.Final
Lucene 5.3.1

The property that controls this behaviour in Hibernate is hibernate.id.new_generator_mappings, which defaults to true for Hibernate 5 -> which means the new TableGenerator will be used instead of the deprecated MultipleHiLoPerTableGenerator .
Spring Boot however defaults this property to false, which means the old generator will be used, unless you explicitly tell it you want the new one.
You need to set the property spring.jpa.hibernate.use-new-id-generator-mappings to true to get the TableGenerator.
See https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-1.4-Release-Notes#generator-mappings

How to migrate the UrlType from Hibernate 3.6 to 4.3 without changing database schema?

I'm in the process of migrating some code from Hibernate v3.4 to v4.3.10. As database I'm using H2.
When generating DDL, Hibernate 3.4 translates a java.net.URL field named myUrl into:
myUrl BINARY(255),
Now, when using Hibernate 4.3.10 the very same Java code gets "translated" into
myUrl VARCHAR(255),
Looking through documentation it seems that Hibernate 3.6 introduced a new type concept ("type registry") and specifically java.net.URL is not mapped to binary, but to varchar, which explains the different generated DDL above.
Question
How do I migrate my 3.4 code to 4.3.10 while not changing the database. I.e., I'd like to be able to read the old database with Hibernate 4.3.10 annotated code.
The code in question is currently trivial:
#Entity
// anything to add here?
public class SomeClass {
// what do I need to add here?
private java.net.URL myUrl;
...
}

To answer my own question - this seems to work:
#Entity
public class SomeClass {
#Lob
#Column(columnDefinition = "binary(255)")
private java.net.URL myURL;
...
}
Additional info: It's a bad idea to use properties of type URL as persistent properties, as during the url.equals(otherUrl) call the Java URLStreamHandler attempts to resolve the URL, i.e. a DNS lookup occurs. When you're on a slow connection, this will kill your performance, as you'll have to wait for the call to succeed or time out...

Can JPA entities be serialized to disk?

I have two machines:
A) Windows XP, JDK 1.7.45
B) Windows Server 2003, JDK 1.7.45
In machine A I can successfully serialize an object to file system and its children and deserialize back.
In machine B, when I deserialize, the children objects are missing. No exception at any stage is thrown.
If I copy the serialized file from A to B then deserialization in B creates the child objects just fine.
This points to a problem in serialization in B.
The problem does not happen with very simple objects. But, when I use objects annotated with JPA, the problem happens.
#Entity
#Table(name="...")
#NamedQuery(name="Category.findAll", query="SELECT c FROM Category c")
public class Category implements Serializable {
private static final long serialVersionUID = 1L;
#Id
#Column(name="...")
private long id;
#Transient
private List<Category> subCategories; //These go missing
...
}
This problem happens for only certain but not all JPA entity classes.
Any idea what might be causing this? Can JPA entities be serialzed without issues? My eventual goal is to cache JPA entities in Couchbase. This works in A, but fails in B. Even simple disk based serialization has problem in B as described here.

There is nothing that prevents you from serializing JPA entities, after all they are POJOs. But what could be happening is that when you try to deserialize it you can't because in the other JVM it doesn't have in the classpath the JPA annotations. Anyway, it should be throwing an exception, so recheck your log.

Here is the tool for you:
EclipseLink MOXy is an implementation of JAXB (JSR-222) specification. As EclipseLink also provides a JPA implementation many of its extensions are aimed at mapping JPA entities:
#XmlInverseReference for supporting bidirectional relationships (see: http://blog.bdoughan.com/2010/07/jpa-entities-to-xml-bidirectional.html)
#XmlPath for mapping embedded IDs (see: http://blog.bdoughan.com/2010/07/xpath-based-mapping.html).
#XmlJoinNodes (similar to JPA's #JoinColumns) when you need to map by key/foreign key.

org.hibernate.annotations.Entity deprecated in Hibernate 4?

I am attempting to update to Hibernate 4 and I am getting that org.hibernate.annotations.Entity is deprecated. None of the documentation however seems to indicate that this is the case. Anyone have any insight into this?
#org.hibernate.annotations.Entity(dynamicUpdate = true)

Yes it is deprecated in 4.0+:
Deprecate org.hibernate.annotations.Entity
Its individual attributes/values should become annotations.
Schedule for removal in 4.1
You should use #DynamicUpdate instead
Here is a fixed JIRA talking about it.

From Hibernate Getting Started Guide :
The #javax.persistence.Entity annotation is used to mark a class as
an entity. It functions the same as the class mapping element
discussed in Section 2.3, "The mapping file". Additionally the
#javax.persistence.Table annotation explicitly specifies the table
name. Without this specification, the default table name would be
EVENT).
Since org.hibernate.annotations.Entity has been deprecated you should use the Java EE annotation. Also, as tolitius already mentioned, for the annotation configurations of #org.hibernate.annotations.Entity, you should use the respective annotation, e.g. #DynamicUpdate.
Hope that helps.
Note: Event is the name of the class that is annotated in the example, this is why it states "default table name would be EVENT".

Use the JPA #Entity annotation instead of the Hibernate #Entity annotation. Look in your imports, it should say
import javax.persistence.Entity;
and not
import org.hibernate.annotations.Entity;

For future purpose, please refer the deprecated API list for Hibernate 4.0. The link is as follows:-
Deprecated API

org.hibernate.annotations vs. javax.persistence

Is it a bad idea to use the annotations from the
javax.persistence package
instead of using the
org.hibernate.annotations annotations
I know that using javax.peristence does introduce yet another dependency. But if I ignore that, what are the pros/cons?

Quite the opposite.
Hibernate is an implementation of the Java Persistence API, and where possible, you should use the standard annotations (in javax.persistence). This way, you could theoretically run your code on other JPA implementations.
Only when you need Hibernate-specific functionality should you use the Hibernate annotations.
The extra dependency is only on the JPA interface/annotation jar files and very light.

Another cons in:
http://www.mkyong.com/hibernate/cascade-jpa-hibernate-annotation-common-mistake/
where this:
#OneToMany(fetch = FetchType.LAZY,
cascade = {CascadeType.PERSIST,CascadeType.MERGE },
mappedBy = "stock")
public Set<StockDailyRecord> getStockDailyRecords() {
return this.stockDailyRecords;
}
with this:
stockDailyRecords.setStock(stock);
stock.getStockDailyRecords().add(stockDailyRecords);
session.save(stock);
session.getTransaction().commit();
won't work as #OneToMany is from JPA, it expects a JPA cascade – javax.persistence.CascadeType. However when you save it with Hibernate session, org.hibernate.engine.Cascade will do the following check:
if ( style.doCascade( action ) ) {
and Hibernate save process will causing a ACTION_SAVE_UPDATE action, but the JPA will pass a ACTION_PERSIST and ACTION_MERGE, it will not match and cause the cascade to fail to execute.

I used javax.persistence annotation, and when I replaced Tomcat 6.0 with my Glass Fish, then Tomcat 6.0 included another javax.persistence package that messed everything. I don't think it's a good idea to use javax.persistence annotation. God know what the hell happened with Tomcat and javax.persistence!

Officially recommended to mix JPA and Hibernate annotations in the case of setting cascading options, see
Hibernate docs. 2.4.7. Cascade. If you using only JPA annotations, in case of unidirectional mapping (no field of Foo type in Employer.java) you still getting "cannot save transient object Employer" in the call session.SaveOrUpdate. Cure is using hibernate-style #Cascade together with cascade={...}:
class Foo {
#OneToMany( cascade = {CascadeType.PERSIST, CascadeType.MERGE} )
#Cascade(org.hibernate.annotations.CascadeType.REPLICATE)
public Collection<Employer> getEmployers()
...
}