For a lot of your questions, I'd highly suggest reading [1] and [2]. They
are mostly the same content (asciidoc versus docbook).
[1] -
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@hibernate.org]
*Sent:* donderdag 13 augustus 2015 4:24
*To:* Koen Serneels; hibernate-dev(a)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-migrat....
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