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