This is mentioned...
Its not just org.hibernate.transaction.CMTTransactionFactory that was
removed; all of the TransactionFactory classes were removed. Actually I
think we should add them as resolvable names:
* org.hibernate.transaction.CMTTransactionFactory
->
org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorBuilderImpl
* org.hibernate.transaction.JTATransactionFactory
->
org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorBuilderImpl
* org.hibernate.transaction.JDBCTransactionFactory ->
org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorBuilderImpl
Add a Jira if you'd like to see them mapped.
On Mon, Nov 2, 2015 at 9:51 AM Scott Marlow <smarlow(a)redhat.com> wrote:
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> 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