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 <k...@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: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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
