[hibernate-dev] Hibernate5 migration

[Steve Ebersole]

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
>