[Hibernate-JIRA] Created: (JPA-4) PersistenceUtil.isLoaded() fails with a ClassCastException in Websphere 7
by Mike Youngstrom (JIRA)
PersistenceUtil.isLoaded() fails with a ClassCastException in Websphere 7
-------------------------------------------------------------------------
Key: JPA-4
URL: http://opensource.atlassian.com/projects/hibernate/browse/JPA-4
Project: Java Persistence API
Issue Type: Bug
Affects Versions: 1.0.0
Environment: Websphere 7 Hibernate 3.5
Reporter: Mike Youngstrom
To duplicate deploy a .war with hibernate 3.5 to Websphere with the contextlistener below. You need to set the classloader to "parent last" so that your application will use Hibernate's JPA 2 API instead of Webspheres JPA 1 API.
package test;
import javax.persistence.Persistence;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
public class TestListener implements ServletContextListener {
@Override
public void contextDestroyed(ServletContextEvent arg0) {
}
@Override
public void contextInitialized(ServletContextEvent arg0) {
System.out.println("Result of isLoaded: "+Persistence.getPersistenceUtil().isLoaded(new Object()));
}
}
Throws the exception below.
It appears the problem is that PersistenceProviderResolverHolder.PersistenceProviderResolverPerClassLoader scans all of the classloader levels to find PersistenceProviders. This is finding Websphere's OpenJPA provider in a different classloader than the application and hence with a different JPA API. Although this example happens in Websphere 7 it would in theory also happen anytime Websphere is used in an app server with another JPA implementation that cannot be removed from the server.
java.lang.ClassCastException: com.ibm.websphere.persistence.PersistenceProviderImpl incompatible with javax.persistence.spi.PersistenceProvider
at javax.persistence.Persistence$1.isLoaded(Persistence.java:92)
at test.TestListener.contextInitialized(TestListener.java:20)
at com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1681)
at com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:374)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:299)
at com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:100)
at com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:166)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:731)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:616)
at com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:376)
at com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:668)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1122)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1315)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:623)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:940)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:725)
at com.ibm.ws.runtime.component.ApplicationMgrImpl$1.run(ApplicationMgrImpl.java:1266)
at com.ibm.ws.security.auth.ContextManagerImpl.runAs(ContextManagerImpl.java:4509)
at com.ibm.ws.security.auth.ContextManagerImpl.runAsSystem(ContextManagerImpl.java:4687)
at com.ibm.ws.security.core.SecurityContext.runAsSystem(SecurityContext.java:255)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplicationDynamically(ApplicationMgrImpl.java:1271)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:2043)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:439)
at com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:123)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:382)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.startCompositionUnit(CompositionUnitMgrImpl.java:653)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.startCompositionUnit(CompositionUnitMgrImpl.java:615)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:1177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:600)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:37)
at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:600)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:244)
at javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1086)
at javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:967)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:848)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:773)
at com.ibm.ws.management.AdminServiceImpl$1.run(AdminServiceImpl.java:1320)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
at com.ibm.ws.management.AdminServiceImpl.invoke(AdminServiceImpl.java:1213)
at com.ibm.ws.management.application.sync.StartDeploymentTask.startDeployment(StartDeploymentTask.java:236)
at com.ibm.ws.management.application.sync.StartDeploymentTask.fullAppUpdate(StartDeploymentTask.java:113)
at com.ibm.ws.management.application.sync.StartDeploymentTask.performTask(StartDeploymentTask.java:101)
at com.ibm.ws.management.application.sync.AppBinaryProcessor$ExpandApp.expand(AppBinaryProcessor.java:1556)
at com.ibm.ws.management.application.sync.AppBinaryProcessor.postProcessSynchronousExt(AppBinaryProcessor.java:654)
at com.ibm.ws.management.bla.sync.BLABinaryProcessor.postProcess(BLABinaryProcessor.java:569)
at com.ibm.ws.management.bla.sync.BLABinaryProcessor.onChangeCompletion(BLABinaryProcessor.java:451)
at com.ibm.ws.management.repository.FileRepository.postNotify(FileRepository.java:1915)
at com.ibm.ws.management.repository.FileRepository.update(FileRepository.java:1424)
at com.ibm.ws.management.repository.client.LocalConfigRepositoryClient.update(LocalConfigRepositoryClient.java:189)
at com.ibm.ws.sm.workspace.impl.WorkSpaceMasterRepositoryAdapter.update(WorkSpaceMasterRepositoryAdapter.java:655)
at com.ibm.ws.sm.workspace.impl.RepositoryContextImpl.update(RepositoryContextImpl.java:1954)
at com.ibm.ws.sm.workspace.impl.RepositoryContextImpl.synch(RepositoryContextImpl.java:1902)
at com.ibm.ws.sm.workspace.impl.WorkSpaceImpl.synch(WorkSpaceImpl.java:511)
at com.ibm.ws.management.configservice.ConfigServiceImpl.save(ConfigServiceImpl.java:703)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:600)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:37)
at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:600)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:244)
at javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1086)
at javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:967)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:848)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:773)
at com.ibm.ws.management.AdminServiceImpl$1.run(AdminServiceImpl.java:1320)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
at com.ibm.ws.management.AdminServiceImpl.invoke(AdminServiceImpl.java:1213)
at com.ibm.ws.management.connector.AdminServiceDelegator.invoke(AdminServiceDelegator.java:181)
at com.ibm.ws.management.connector.rmi.RMIConnectorService.invoke(RMIConnectorService.java:282)
at com.ibm.ws.management.connector.rmi._RMIConnectorService_Tie.invoke(_RMIConnectorService_Tie.java:395)
at com.ibm.ws.management.connector.rmi._RMIConnectorService_Tie._invoke(_RMIConnectorService_Tie.java:160)
at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:622)
at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:475)
at com.ibm.rmi.iiop.ORB.process(ORB.java:513)
at com.ibm.CORBA.iiop.ORB.process(ORB.java:1574)
at com.ibm.rmi.iiop.Connection.respondTo(Connection.java:2841)
at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2714)
at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:63)
at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:118)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1550)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[Hibernate-JIRA] Created: (HV-524) java.util.NoSuchElementException in type level validation using EclipseLink
by sinuhepop (JIRA)
java.util.NoSuchElementException in type level validation using EclipseLink
---------------------------------------------------------------------------
Key: HV-524
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-524
Project: Hibernate Validator
Issue Type: Bug
Components: validators
Affects Versions: 4.2.0.Final
Environment: EclipseLink 2.2.0
Reporter: sinuhepop
When EclipseLink obtains an entity from database does a validation. It works ok with field level validators, but throws an exception with type level ones.
The problem is that SingleThreadCachedTraversableResolver sends an "empty" pathToTraversableObject to EL's BeanValidationListener, who finally fails when calling "pathToTraversableObject.iterator().next().getName()".
I don't know who (HV or EL) is responsible of the issue, but it worked with HV-4.0.2.GA.
Thanks for your effort.
Sinuhé.
Caused by: javax.validation.ValidationException: Call to TraversableResolver.isReachable() threw an exception
at org.hibernate.validator.engine.ValidatorImpl.isValidationRequired(ValidatorImpl.java:1251) ~[hibernate-validator-4.2.0.Final.jar:4.2.0.Final]
at org.hibernate.validator.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:448) ~[hibernate-validator-4.2.0.Final.jar:4.2.0.Final]
at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForDefaultGroup(ValidatorImpl.java:397) ~[hibernate-validator-4.2.0.Final.jar:4.2.0.Final]
at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:361) ~[hibernate-validator-4.2.0.Final.jar:4.2.0.Final]
at org.hibernate.validator.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:313) ~[hibernate-validator-4.2.0.Final.jar:4.2.0.Final]
at org.hibernate.validator.engine.ValidatorImpl.validate(ValidatorImpl.java:139) ~[hibernate-validator-4.2.0.Final.jar:4.2.0.Final]
at org.eclipse.persistence.internal.jpa.metadata.listeners.BeanValidationListener.validateOnCallbackEvent(BeanValidationListener.java:84) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913]
at org.eclipse.persistence.internal.jpa.metadata.listeners.BeanValidationListener.preUpdate(BeanValidationListener.java:72) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913]
at org.eclipse.persistence.descriptors.DescriptorEventManager.notifyListener(DescriptorEventManager.java:671) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913]
at org.eclipse.persistence.descriptors.DescriptorEventManager.notifyEJB30Listeners(DescriptorEventManager.java:641) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913]
at org.eclipse.persistence.descriptors.DescriptorEventManager.executeEvent(DescriptorEventManager.java:200) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913]
at org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.calculateChanges(DeferredChangeDetectionPolicy.java:85) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913]
at org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.calculateChangesForExistingObject(DeferredChangeDetectionPolicy.java:54) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913]
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.calculateChanges(UnitOfWorkImpl.java:623) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913]
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1496) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913]
at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.commitRootUnitOfWork(RepeatableWriteUnitOfWork.java:264) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913]
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitAndResume(UnitOfWorkImpl.java:1130) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913]
at org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.commitInternal(EntityTransactionImpl.java:84) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913]
... 73 common frames omitted
Caused by: java.util.NoSuchElementException: null
at java.util.Collections$EmptyIterator.next(Unknown Source) ~[na:1.7.0]
at org.eclipse.persistence.internal.jpa.metadata.listeners.BeanValidationListener$AutomaticLifeCycleValidationTraversableResolver.isRootObjectPath(BeanValidationListener.java:180) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913]
at org.eclipse.persistence.internal.jpa.metadata.listeners.BeanValidationListener$AutomaticLifeCycleValidationTraversableResolver.isReachable(BeanValidationListener.java:123) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913]
at org.hibernate.validator.engine.resolver.SingleThreadCachedTraversableResolver.isReachable(SingleThreadCachedTraversableResolver.java:46) ~[hibernate-validator-4.2.0.Final.jar:4.2.0.Final]
at org.hibernate.validator.engine.ValidatorImpl.isValidationRequired(ValidatorImpl.java:1242) ~[hibernate-validator-4.2.0.Final.jar:4.2.0.Final]
... 90 common frames omitted
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[Hibernate-JIRA] Created: (HV-509) Property path is wrong for cascaded validation of class-level constraints
by Gunnar Morling (JIRA)
Property path is wrong for cascaded validation of class-level constraints
-------------------------------------------------------------------------
Key: HV-509
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-509
Project: Hibernate Validator
Issue Type: Bug
Components: engine
Affects Versions: 4.2.0.Final
Reporter: Gunnar Morling
Fix For: 4.3.0.next
If a bean is validated which has a collection-typed member annotated with {{@Valid}} and of a type which itself has a class-level constraint, then the property pathes of the violations of that class-level constraint are wrong. The following shows an example:
{code:java}
public class FooTest {
@ValidFoo
private static class Foo {}
@Constraint(validatedBy = { ValidFooValidator.class })
@Target({ TYPE })
@Retention(RUNTIME)
public @interface ValidFoo {
String message() default "{ValidFoo.message}";
Class<?>[] groups() default { };
Class<? extends Payload>[] payload() default { };
}
public static class ValidFooValidator implements ConstraintValidator<ValidFoo, Foo> {
public void initialize(ValidFoo annotation) {}
public boolean isValid(Foo foo, ConstraintValidatorContext context) {
return false;
}
}
private static class Bar {
@Valid
private List<Foo> foos = Arrays.asList(new Foo(), new Foo());
}
@Test
public void testBar() {
Validator validator = Validation.buildDefaultValidatorFactory().getValidator();
Set<ConstraintViolation<Bar>> violations = validator.validate(new Bar());
//fails as pathes currently are "foos[1]", "foos[1]"
ConstraintViolationAssert.assertCorrectPropertyPaths(violations, "foos[0]", "foos[1]");
}
}
{code}
The cause seems to be that the same {{PathImpl}} instance is used within both violations. When the 2nd violation is created, the index of the shared {{PathImpl}} instance originally created for the first violation is set from 0 to 1.
I think this can be circumvented by creating a copy of the path in the constructor of {{ConstraintValidatorContextImpl}}.
Forum reference: https://forum.hibernate.org/viewtopic.php?f=9&t=1011952
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[Hibernate-JIRA] Created: (HHH-2965) When using Criteria.setResultTransformer(CriteriaSpecification.ALIAS_TO_ENTITY_MAP) method aliases need to be optional
by Ittai Zeidman (JIRA)
When using Criteria.setResultTransformer(CriteriaSpecification.ALIAS_TO_ENTITY_MAP) method aliases need to be optional
----------------------------------------------------------------------------------------------------------------------
Key: HHH-2965
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2965
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Environment: 3.2.2 Oracle 10G
Reporter: Ittai Zeidman
Priority: Critical
now when using the CriteriaSpecification- ALIAS_TO_ENTITY_MAP the convertion to map is using the aliases array, if it does not find an alias for the property it is not included in the map. I think that if no alias is defined then the propertyName attribute needs to be assigned as the key for the value in the hashmap.
I came across this issue as i have many mapped entities in my system and when using projections i need to use the resultTransformer. this is critical as when using aliases it is duplicated not only to the select clause but to the where clause only which is another open bug (#HB-1331). If one bug is closed then the other can be considered as minor as i can give aliases to every property i need if it does not affect my where clause.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[Hibernate-JIRA] Created: (JPA-14) OPTIMISTIC_FORCE_INCREMENT is not incrementing version field of non-dirty entities
by Behrang Saeedzadeh (JIRA)
OPTIMISTIC_FORCE_INCREMENT is not incrementing version field of non-dirty entities
----------------------------------------------------------------------------------
Key: JPA-14
URL: http://opensource.atlassian.com/projects/hibernate/browse/JPA-14
Project: Java Persistence API
Issue Type: Bug
Environment: MySQL 5.1.53 with InnoDB, Hibernate 3.1.6 Final, Java 1.6.0_22
Reporter: Behrang Saeedzadeh
According to the JPA 2 spec:
{quote}
If transaction T1 calls {{lock(entity, LockModeType.OPTIMISTIC_FORCE_INCREMENT)}} on a versioned object, the entity manager must avoid the phenomena P1 and P2 (as with {{LockModeType.OPTIMISTIC}}) and must also force an update (increment) to the entity's version column. A forced version update may be performed immediately, or may be deferred until a flush or commit. If an entity is removed before a deferred version update was to have been applied, the forced version update
is omitted.
{quote}
However, Hibernate is not incrementing the version field when the entity is not altered in the transaction:
{code}
final EntityManager em = factory.createEntityManager();
em.getTransaction().begin();
VersionedEntity entity = em.find(VersionedEntity.class, id);
em.lock(entity, LockModeType.PESSIMISTIC_FORCE_INCREMENT);
em.getTransaction().commit();
em.close();
{code}
However, the spec says ??must also force an update (increment) to the entity's version column?? and does not give the option to ignore updating the version number if the entity was not dirty.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[Hibernate-JIRA] Created: (HHH-6042) To much columns in select queries after creating criteria with join
by Karol Kowalczyk (JIRA)
To much columns in select queries after creating criteria with join
-------------------------------------------------------------------
Key: HHH-6042
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6042
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.6
Environment: <dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>3.2.6.ga</version>
</dependency>
Any database
Reporter: Karol Kowalczyk
Attachments: AbstractEntityJoinWalker.java, Loader.java
When I create criteria for any class with any value of property of association f.e.:
java code:
eventDCriteria = DetachedCriteria.forClass(Event.class);
personDCriteria = eventDCriteria.createCriteria("participants");
personDCriteria.add(Expression.eq("age", 41));
List<Event> events=(List<Event>)getHibernateTemplate().findByCriteria(eventDCriteria, 0, 2);
class mappings:
<class name="Event" table="EVENTS">
<id name="id" column="EVENT_ID">
<generator class="native"/>
</id>
<property name="date" type="timestamp" column="EVENT_DATE"/>
<property name="title"/>
<set name="participants" table="PERSON_EVENT" inverse="true">
<key column="EVENT_ID"/>
<many-to-many column="PERSON_ID" class="Person"/>
</set>
</class>
<class name="Person" table="PERSON">
<id name="id" column="PERSON_ID">
<generator class="native"/>
</id>
<property name="age"/>
<property name="firstname"/>
<property name="lastname"/>
<set name="events" table="PERSON_EVENT" >
<key column="PERSON_ID"/>
<many-to-many column="EVENT_ID" class="Event"/>
</set>
<set name="emailAddresses" table="PERSON_EMAIL_ADDR" >
<key column="PERSON_ID"/>
<element type="string" column="EMAIL_ADDR"/>
</set>
</class>
a Hibernate still creates select query f.e.:
select e.EVENT_ID, e.EVENT_DATE, e.title, pe.EVENT_ID, pe.PERSON_ID, p.PERSON_ID, p.age, p.firstname, ...
from EVENTS e
inner join PERSON_EVENT pe on pe.EVENT_ID=e.EVENT_ID
inner join PERSON p on p.PERSON_ID=pe.PERSON_ID
where p.age=?;
Why this hibernates query have UNNECESSARY list of columns: pe.EVENT_ID, pe.PERSON_ID, p.PERSON_ID, p.age, p.firstname, ...?
This query is not INDEXONLY for any databases.
More EFFECTIVE query is:
select e.EVENT_ID, e.EVENT_DATE, e.title
from EVENTS e
inner join PERSON_EVENT pe on pe.EVENT_ID=e.EVENT_ID
inner join PERSON p on p.PERSON_ID=pe.PERSON_ID
where p.age=?;
A prepared only for my two changes in hibernate: Loader.java and AbstractEntityJoinWalker.java to get more effective selects.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[Hibernate-JIRA] Created: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
by Zach Kurey (JIRA)
Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
---------------------------------------------------------------------------------------------------------
Key: HSEARCH-886
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886
Project: Hibernate Search
Issue Type: New Feature
Components: engine, mapping
Reporter: Zach Kurey
Frequently its desirable to index a particular embedded type differently depending on the use case of the referencing type that is the primary subject being indexed. Additionally, depth in general causes many more paths to be included in a document than necessary for a particular index. This makes tuning of indexing to eliminate problem paths difficult, and sometimes impossible if a particular object model re-uses a lot of types.
The proposal/improvement has already been discussed more in depth here: http://www.mail-archive.com/hibernate-dev@lists.jboss.org/msg06548.html, and what follows reflects some of that discussion.
As an example of how specific paths could be configured for indexing:
@Indexed
class A{
@IndexEmbedded(
depth=0,
@IndexPaths(paths={"d.one", "d.two"})
)
private C see;
}
@Indexed
class B{
@IndexEmbedded(
depth=0,
@IndexPaths(paths={"foo"})
)
private C see;
}
class C{
@IndexEmbedded
private Collection<D> d;
@Field
private int foo;
}
class D{
@Field
int one;
@Field
int two;
}
Index A would contain: d.one, and d.two
Index B would contain: foo, but would NOT contain anything from path 'd'.
Perhaps indexing path 'd' has a performance impact that is desirable to eliminate for B, but acceptable or necessary for A. This ability would also help to eliminate the bloat of unnecessary fields in lucene documents; which may not itself be a performance problem, but leaves a lot of things to rule out when tracking down indexing issues(both performance or content).
Lastly. To be clear, the above proposal(which really Sanne came up with in the email thread) does not conflict with depth. Here are some further examples of how depth may interact with explicit paths:
@IndexEmbedded(depth=3, paths={"a.b.c.d.e"})
Says to index all paths up to depth 3, but additionally index path 'a.b.c.d.e'.
@IndexEmbedded(depth=0, paths={"a.b.c.d.e"})
Says to only index path 'a.b.c.d.e'
@IndexEmbedded( paths={"a.b.c.d.e"})
Default behavior, depth is unlimited, specifying a.b.c.d.e is redundant in this case.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month