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:st...@hibernate.org] 
Sent: donderdag 13 augustus 2015 4:24
To: Koen Serneels; hibernate-dev@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

_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Reply via email to