[hibernate-dev] Hibernate5 migration

Koen Serneels ks at error.be
Thu Aug 13 00:48:33 EDT 2015


Hi Steve,

 

Let me clarify the first two questions:

 

I’m looking for an entry point/hook in H5 for altering existing class mappings. For example; some of our entities are supposed to be immutable, but only in production mode.

When running our tests we are using that same model to setup data in an in-memory database. If the entities would be hardcoded immutable then we would be problematic to use them fully for manipulating setup data in our tests. So, in test mode we actually need the entities to be mutable instead.

To accomplish this we  are retrieving  the classMappings from the Configuration which gives us the PersistentClass meta-data. On  this which we can then toggle the mutable flag depending.

Since that functionality has now been refactored, I thought that MetadataContributor was the way to go in H5 as it lets me access InFlightMetadataCollector which gives access to getEntityBindingMap which allows to retrieved the PersistentClasses.

 

However, from the source code I understand that the MetadataContributor can only be configured using ServiceLoader. This means it will not be so straightforward/clean to enable or disable that said MetadataContributor dynamically. Now you suggest:  But if a piece of code is able to determine whether or not to register a MetadataContributor, it could simply contribute said metadata, no? yes, but this is probably where my understanding is falling short; I was under the impression that the MetadataContributor is *the* new way for contributing changes or additions to existing meta-data. If there is another (programmatic) way without having to register MetadataContributor, then by all means, but how/where?

 

On the JTA question:

 

My question has been answered, thanks, but just to clarify: when using JTA, we can configure the shorthand alias ‘jta’ for the coordinator as you state.

With the second part I meant; what if we are _not_ using JTA but are in local transaction mode, should we then also explicitly configure the coordinator (with short name ‘jdbc’ in that case) or will it be the default? Again you confirm that ‘jdbc’ is the default so when not using JTA no coordinator setting is required

 

For the last question:

 

Ok thanks for pointing that out. Is there an easy way to get hold of the org.hibernate.boot.Metadata which I need to pass to SchemaCreator/SchemaDropper?

I could also use SchemaExport directly from within code, but afaik it will rebuild the metadata which will probably take longer…

 

To give some background how I’m using this:  in some types of test we actually commit data to our in-memory database. In order to clear the database between tests, we simply drop and recreate the entire schema based on the DDL. This was the fastest solution with the least amount of impact. For the record: I’m aware there are other solutions for this, but not all of them are feasible. I’m leaving out the details here as it would go off topic – at the moment I’m just looking for a way to migrate it to H5 keeping the same functionality we have been using (extract the create/drop DDL from a live SF as fast as possible)

 

Thanks,

 

Koen.

 

From: Steve Ebersole [mailto:steve at hibernate.org] 
Sent: donderdag 13 augustus 2015 4:24
To: Koen Serneels; hibernate-dev at lists.jboss.org
Subject: Re: [hibernate-dev] Hibernate5 migration

 

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



More information about the hibernate-dev mailing list