[hibernate-dev] Hibernate5 migration

Mon Nov 2 10:50:43 EST 2015

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
>