[hibernate-dev] Hibernate5 migration

[Steve Ebersole]

This is mentioned...
https://github.com/hibernate/hibernate-orm/blob/master/migration-guide.adoc#transactions

Its not just org.hibernate.transaction.CMTTransactionFactory that was
removed; all of the TransactionFactory classes were removed.  Actually I
think we should add them as resolvable names:

* org.hibernate.transaction.CMTTransactionFactory
-> org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorBuilderImpl
* org.hibernate.transaction.JTATransactionFactory
-> org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorBuilderImpl
* org.hibernate.transaction.JDBCTransactionFactory ->
org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorBuilderImpl

Add a Jira if you'd like to see them mapped.


On Mon, Nov 2, 2015 at 9:51 AM Scott Marlow <smarlow at redhat.com> wrote:

> Should the ORM 5 migration documentation [3] mention that
> "hibernate.transaction.factory_class" can no longer be set to
> "org.hibernate.transaction.CMTTransactionFactory"?  I think that
> CMTTransactionFactory is deleted in 5.0.
>
> Scott
>
> [3]
> https://github.com/hibernate/hibernate-orm/blob/master/migration-guide.adoc
>
>
> On 08/13/2015 08:38 AM, Steve Ebersole wrote:
> > For a lot of your questions, I'd highly suggest reading [1] and [2].
> They
> > are mostly the same content (asciidoc versus docbook).
> >
> > [1] -
> >
> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
> > [2] -
> >
> http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#bootstrap-native
> >
> >
> >
> >
> > On Wed, Aug 12, 2015 at 11:58 PM Koen Serneels <ks at error.be> wrote:
> >
> >> 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
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev