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?

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).

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?

Do we need to configure anything special in case of resource local TX or is JdbcResourceLocalTransactionCoordinatorImpl the default?

removed from Configuration. Is there a way to access this in another way?

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

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/NativeBoot... > [2] - > http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#boot... > > > > > On Wed, Aug 12, 2015 at 11:58 PM Koen Serneels <ks(a)error.be&gt; 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@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 >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev