Hibernate 4 Multi-tenancy Issue - No Entity Persisters Found
by amit shah
Hello,
I have been trying to integrate hibernate 4 multi-tenancy support in our
application but I get the below exception on executing an hql query
java.lang.ArrayIndexOutOfBoundsException: 0
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.resultClassChecking(AbstractEntityManagerImpl.java:362)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:344)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler.invoke(ExtendedEntityManagerCreator.java:344)
at com.sun.proxy.$Proxy288.createQuery(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:291)
at com.sun.proxy.$Proxy43.createQuery(Unknown Source)
The hql query is -
List<Field> fields = entityManager.createQuery("from " +
Employee.class.getName() +
" where " + getQueryForInClause("id", ids),
Employee.class).getResultList();
On debugging hibernate source, I realize that this is because
hibernate's *SessionFactory
instance does not have any entityPersister instances* due to which the hql
query does have any translator's.
Is it because the Entity beans are not getting scanned? If so what could be
the cause?
The entityFactory spring is declared as below
<property name="persistenceProviderClass"
value="org.hibernate.jpa.HibernatePersistenceProvider"/><property
name="persistenceXmlLocation"
value="/com/software/persistence/persistence.xml"/><property
name="jpaProperties">
<map>
<entry key="hibernate.id.new_generator_mappings" value="true"/>
<entry key="hibernate.cache.use_second_level_cache" value="false"/>
<entry key="hibernate.dialect"
value="com.software.persistence.ExtendedOracle10gDialect"/>
<entry key="hibernate.jdbc.batch_size" value="10"/>
<entry key="hibernate.jdbc.batch_versioned_data" value="true"/>
<entry key="hibernate.jdbc.batch.builder"
value="com.software.persistence.OracleBatchBuilder"/>
<entry key="hibernate.multiTenancy" value="DATABASE"/>
<entry key="hibernate.tenant_identifier_resolver"
value="com.software.persistence.MultitenantIdentifierResolver"/>
<entry key="hibernate.multi_tenant_connection_provider"
value-ref="multiTenantConnectionProvider" />
</map></property>
Thanks,
Amit.
P.S - Since I am not getting any traction on this on the hibernate user
forum, I am re-posting this question on the dev forum.
8 years, 9 months
Building snapshots of Hibernate ORM / master
by Sanne Grinovero
Hi all,
I'm trying to build Hibernate ORM's latest to try debugging some of
the latest changes for Wildfly and Search integrations.
The README mentions I should be able to
./gradlew clean publishToMavenLocal
but that fails on the hibernate-osgi module. I then tried "publish" to
upload a snapshot, but that prouces the same error message:
:hibernate-osgi:publishMavenJavaPublicationToJboss-snapshots-repositoryRepository
FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task
':hibernate-osgi:publishMavenJavaPublicationToJboss-snapshots-repositoryRepository'.
> Failed to publish publication 'mavenJava' to repository 'jboss-snapshots-repository'
> Invalid publication 'mavenJava': artifact file does not exist:
'/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/target/karafFeatures/hibernate-osgi-5.0.1-SNAPSHOT-karaf.xml'
On the version, I was expecting it to build some "5.0.0-SHAPSHOT" but
it's actually building a "5.0.1-SNAPSHOT", is that expected?
I was hoping I could ignore the osgi module and take what it built to
experiment with Scott's branch, but while on HHH-9887 he mentions
being down to two failures, I'm having still dozens of failures so I
suspect I'll need some advice on the build.
Scott, could you share which exact commit id did you use to test
Hibernate ORM on your branch "hibernate5_july2", and how I can build
it like yours ?
Thanks,
Sanne
8 years, 9 months
HSEARCH: Removing dynamic analyzer mapping?
by Sanne Grinovero
Among the many changes of Apache Lucene 5, it is no longer possible to
override the Analyzer on a per-document base.
You have to pick a single Analyzer when opening the IndexWriter.
Of course the Analyzer can still return a different tokenization chain
for each field, but the field->tokenizer mapping has to be consistent
for the lifecycle of the IndexWriter.
This means we might need to drop our "Dynamic Analyzer" feature:
http://docs.jboss.org/hibernate/search/5.4/reference/en-US/html_single/#_...
I did ask to restore the functionality:
https://issues.apache.org/jira/browse/LUCENE-6212
So, the alternatives I'm seeing:
# Dropping the Dynamic Analyzer feature
# Cheat and pass in a mutable Analyzer - needs some caution re concurrent usage
# Cheat and pass in a pre-analyzed Document
# Fork & patch the IndexWriter
Patching the functionality back in Lucene is trivial, but the Lucene
team needs to agree on the use case and then the release time will be
long.
We should discuss both a short-term solution and the better long-term solution.
My favourite long-term solution would be to do pre-analysis: in our
master/slave clustering approach, that would have several other
benefits:
- move the analyzer work to the slaves
- reduce the network payloads
- remove the need to be able to serialize analyzers
But I'd prefer to do this in a second "polishing phase" rather than
consider such a backend rewrite as a blocker for Lucene 5.
WDYT?
Thanks,
Sanne
8 years, 9 months
OGM options and ORM 5 bootstrap
by Gunnar Morling
Hi Emmanuel, all,
Prior to ORM 5, we used to have OgmConfiguration (sub-class of the dreaded
Configuration), which provided an entry point into our custom option API:
OgmConfiguration config = ...
config.configureOptionsFor( MongoDB.class )
.associationStorage(IN_ENTITY)
...
OgmSessionFactory osf = config.buildSessionFactory();
Now as of my current in-flight branch of migrating over to ORM 5, the
equivalent is writing a configurator callback (which also is the only way
today to do it under JPA):
public class MyConfigurator extends OptionConfigurator {
public void configure(Configurable configurable) {
configurable.configureOptionsFor( MongoDB.class )
.associationStorage(IN_ENTITY)
}
}
And then plugging it in like so:
OgmSessionFactory osf = new MetadataSources(
new StandardServiceRegistryBuilder()
.applySetting( "hibernate.ogm.option.configurator",
MyConfigurator.class )
.build();
)
.buildMetadata()
.getSessionFactoryBuilder()
.unwrap( OgmSessionFactoryBuilder.class )
.build();
Do you consider that good enough? The alternative would be providing our
own OgmStandardServiceRegistryBuilder or some unwrap on
StandardServiceRegistryBuilder (it has to be that early, because the
datastore provider service lives in that service registry, and it may
consume settings such as the global write concern which is passed to
MongoDB when connecting). Personally I think what we have is good enough.
Thanks,
--Gunnar
8 years, 9 months
OGM embedded collection handling
by Jonathan Halliday
So I'm tinkering with the cassandra OGM backend, looking particularly at
@ElementCollection since cassandra has native collection types, use of
which would sidestep the current limitations on List's bag semantics at
the same time as improving performance.
The ORM core we sit on assumes that such collections map to a separate
table, that being the Relational Way. So assorted munging of metadata
is needed to change that model in the backend...
At schema definition time it's necessary to identify which Tables should
just pass though to underlying db tables and which should be intercepted
and rewritten as embedded collection types in the owning table. (hint:
associationKeyMetadata.getAssociationKind() ==
AssociationKind.EMBEDDED_COLLECTION)
Having picked out the ones to embed, it's then necessary to figure out
what to embed them into. This is where things get sticky - chaining
through to the EntityKeyMetaData's Table should reveal where the
collection belongs, but it seems that currently
OgmCollectionPersister.targetEntityKeyMetadata initialises that to point
to the embedded table, not the owning entity's table. IMO that's a bug,
but I may be misinterpreting the intent of that metadata. If it is
behaving correctly, then how can the relationship information be discovered?
thanks
Jonathan.
--
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Matt Parson
(USA), Charlie Peters (USA), Michael O'Neill(Ireland)
8 years, 9 months
Problems running matrix tests
by Karel Maesen
I’v tried to run my matrix tests for hibernate-spatial and I’m running into some problems.
First problem is that setting JAVA6_HOME on OS X didn't work because Gradle apparently can’t find the runtime jar (the Home layout of JDK 1.6 on Mac seems to be non-standard). I worked around that by pointing that variable to a JDK1.7.
Next problem is that I now get an exception when I run:
$ ../gradlew -Dhibernate-matrix-databases=`pwd`/databases -Dhibernate-matrix-ignore='mysql50,mysql51,postgresql82,postgresql83,postgresql84' tasks —stacktrace
The exception is:
Caused by: org.gradle.api.internal.plugins.PluginApplicationException: Failed to apply plugin [id 'hibernate-matrix-testing']
at org.gradle.api.internal.plugins.DefaultPluginManager.doApply(DefaultPluginManager.java:160)
at org.gradle.api.internal.plugins.DefaultPluginManager.apply(DefaultPluginManager.java:112)
at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyType(DefaultObjectConfigurationAction.java:113)
at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$200(DefaultObjectConfigurationAction.java:36)
at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$3.run(DefaultObjectConfigurationAction.java:80)
at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:136)
at org.gradle.api.internal.project.AbstractPluginAware.apply(AbstractPluginAware.java:46)
at org.gradle.api.plugins.PluginAware$apply.call(Unknown Source)
at org.gradle.api.internal.project.ProjectScript.apply(ProjectScript.groovy:34)
at org.gradle.api.Script$apply.callCurrent(Unknown Source)
at hibernate_core_28emj67po4a3o66dseh0ycn0w.run(/Users/maesenka/workspaces/github/hibernate-core/hibernate-core/hibernate-core.gradle:8)
at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:74)
... 91 more
Caused by: groovy.lang.MissingPropertyException: No such property: testReportDir for class: org.gradle.api.tasks.testing.Test_Decorated
Possible solutions: testReporter
at org.gradle.api.internal.plugins.ExtraPropertiesDynamicObjectAdapter.setProperty(ExtraPropertiesDynamicObjectAdapter.java:46)
at org.gradle.api.internal.CompositeDynamicObject.setProperty(CompositeDynamicObject.java:122)
at org.gradle.api.tasks.testing.Test_Decorated.setProperty(Unknown Source)
at org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin.prepareNodeTask(MatrixTestingPlugin.groovy:154)
at org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin.this$2$prepareNodeTask(MatrixTestingPlugin.groovy)
at org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin$this$2$prepareNodeTask.callCurrent(Unknown Source)
at org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin.apply(MatrixTestingPlugin.groovy:89)
at org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin.apply(MatrixTestingPlugin.groovy)
at org.gradle.api.internal.plugins.ImperativeOnlyPluginApplicator.applyImperative(ImperativeOnlyPluginApplicator.java:35)
at org.gradle.api.internal.plugins.RuleBasedPluginApplicator.applyImperative(RuleBasedPluginApplicator.java:43)
at org.gradle.api.internal.plugins.DefaultPluginManager.doApply(DefaultPluginManager.java:144)
... 102 more
Anyone an idea on what is going on here? I also tried to run this command on hibernate-core and it produced the same result.
Regards,
Karel
8 years, 9 months