[hibernate-dev] Hibernate5 migration

[Steve Ebersole]

There is a migration guide:
https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md.
It is still a work in progress as in its is not "prettified" yet (as 5.0 is
not final yet.  If things are missing please let us know.

Some answers inline...


- In Hibernate4 we modified mappings on-the-fly by overriding Spring's
> LocalSessionFactoryBean#buildSessionFactory.


> Doing so we could first access the getClassMapping on
> org.hibernate.cfg.Configuration before letting the SF actually build.
>
> However, in Hibernate5 the metadata access has been refactored and is no
> longer part of the Configuration. Should we use MetadataContributor instead
> for these purposes?
>


Depends what you are trying to achieve specifically.  What do you mean by
"modify"?  Do you mean literally that you want to modify (alter) the
existing "class mappings", or do you really mean that you want to add
additional mappings?


- Is there a way to register MetadataContributor dynamically? I see that it
> is being loaded using Java's ServiceLoader.
>
> However, I need some programmatic API access to enable or disable the
> Contributor (for example based on Spring profiles).
>

No there is not a way to register a MetadataContributor programatically.  I
really do not see the benefit of having that as a feature.  Maybe you need
to explain better?  But if a piece of code is able to determine whether or
not to register a MetadataContributor, it could simply contribute said
metadata, no?


- For JTA integration we were using
> org.hibernate.engine.transaction.internal.jta.CMTTransactionFactory, but
> this class is no longer present.
>
> Also in org.hibernate.cfg.AvailableSettings the key that was used
> (hibernate.transaction.factory_class) to configure the factory is also
> removed.
>
> Is hibernate.transaction.coordinator_class the new key we should be using
> instead with
>
> org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordi
> natorImpl as value for JTA?
>

Yes, but I would highly recommend using the short-name config values, e.g.:

hibernate.transaction.coordinator_class=jta

rather than:

hibernate.transaction.coordinator_class=org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl

Both do the same thing, the first form is just better (for many reasons).



> Do we need to configure anything special in case of resource local TX or is
> JdbcResourceLocalTransactionCoordinatorImpl the default?
>

I'm confused with this last piece in combination with the rest of the
questions here.  The rest of the block discusses JTA, but then here you are
asking about JDBC-based transactions.  Regardless, the default
TransactionCoordinator is in fact the JDBC one.


- generateDropSchemaScript and generateSchemaCreationScript have been
> removed from Configuration. Is there a way to access this in another way?
>

Again, depends on exactly what you hope to accomplish here.  Your main
options will be either:
1) grab the org.hibernate.tool.schema.spi.SchemaManagementTool from the
StandardServiceRegistry and use it to obtain the SchemaCreator
and SchemaDropper, passing them the Metadata.
2) Use the org.hibernate.tool.hbm2ddl.SchemaExport class