[Hibernate-JIRA] Updated: (HHH-1123) Cannot put more than 1000 elements in a InExpression
by Strong Liu (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123?page=c... ]
Strong Liu updated HHH-1123:
----------------------------
Attachment: LongInElementsTest.java
Animal.hbm.xml
this restriction on oracle not only affects Criteria, but HQL also
I have created a simple test case attached (LongInElementsTest.java and Animal.hbm.xml)
> Cannot put more than 1000 elements in a InExpression
> ----------------------------------------------------
>
> Key: HHH-1123
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1 rc2, 3.2.0.alpha1
> Environment: Oracle 9i
> Reporter: Alexis Seigneurin
> Assignee: Strong Liu
> Attachments: Animal.hbm.xml, hibernate-inexpression-oracle-3.2.patch, LongInElementsTest.java, patch.txt
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> The number of elements that we can put in a "in" expression is limited to a certain amount (1000 for Oracle, for instance). When creating a criteria query, the org.hibernate.criterion.InExpression class should split the expression into several smaller ones.
> Attached is a patch which splits the expression by slices of 500 elements. For example, if we have 1001 elements to put in the "in" expression, the result would be :
> (entity.field in (?, ?, ?...) or entity.field in (?, ?, ?...) or entity.field in (?))
> The surrounding parantheses are useful to avoid problems with other conditions (a "and" condition taking over the one of the "or" conditions).
--
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, 6 months
[Hibernate-JIRA] Commented: (HHH-1395) Hierarchical entity data management using 'modified preorder tree traversal algorithm' (nested set trees)
by Joonas Koivunen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1395?page=c... ]
Joonas Koivunen commented on HHH-1395:
--------------------------------------
Problem is that detach/join methods use some getters; it's easily fixed by retrieving the values by getId(), however I do not have time to package another release so be aware, if you use the post-update event listener.
> Hierarchical entity data management using 'modified preorder tree traversal algorithm' (nested set trees)
> ----------------------------------------------------------------------------------------------------------
>
> Key: HHH-1395
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1395
> Project: Hibernate Core
> Issue Type: New Feature
> Components: core, query-hql
> Environment: Hibernate 3.1 plus Annotations extending EJB3 implementation
> Reporter: James Salt
> Attachments: nestedset.tar.gz, utils-parent-20091117.tar.gz
>
> Original Estimate: 3 weeks
> Remaining Estimate: 3 weeks
>
> An enhancement to allow entities to exist in a managed tree (DAG) structure, via the use of property annotations and entity annotations. With an extension to the HQL language to mimic the Oracle recusive query clause.
> This would be classically be useful for Bill of Material uses, or any tree like entity structure.
> I have implemented a homebrew approach using the 'adjacency list method' , and a post persist call back method to set the node path. Although I think a more full blown optimised algorithm would be the 'modified preorder tree traversal algorithm'.
> In the annotations world this could be implemented using an annotation like @Hierarchical to the entity, with a @Parent (mask for @ManyToOne) annotation on the parent field/parameter and @Children (mask for @OneToMany) annotation on the list of children entities.
> Then a postupdate method could be implemented for the entity type, that recalculates the tree meta data -i.e. parent, left and right.
> I believe this would be a valuable extension (useful for many common data models) to the hibernate core product that could be exposed through annotations as I have discussed and the hbm.xml.
> The users of such a system would be aware of the performance implications on insert/update/delete, but gain a massive performance gain on querying a tree data model.
>
--
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, 6 months
[Hibernate-JIRA] Commented: (HHH-1395) Hierarchical entity data management using 'modified preorder tree traversal algorithm' (nested set trees)
by Joonas Koivunen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1395?page=c... ]
Joonas Koivunen commented on HHH-1395:
--------------------------------------
I've found a problem from the update code; I'm working to reproduce and fix it, but as of yet, I cannot reproduce it even in unit tests (not included in the distribution).
I get {{org.hibernate.AssertionFailure: collection [groups.entities.Group.children] was not processed by flush()}} in the following situation:
# open session on request (OpenSessionInView filter)
# bind value from html <select> form post
#* {{Session.load(Group.class, 1L);}}
#* {{Group.setParent(boundValue);}}
# setup transaction
# {{Session.saveOrUpdate(modifiedGroup);}}
#* all goes great
# commit (implicit flush)
#* the assertion failure
Still investigating this one. But as discussed with Steve Ebersole at irc, he feels that a new kind of persister might be the best solution for Nested Set datatypes.
I'm yet to discuss this with Christian Bauer..
> Hierarchical entity data management using 'modified preorder tree traversal algorithm' (nested set trees)
> ----------------------------------------------------------------------------------------------------------
>
> Key: HHH-1395
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1395
> Project: Hibernate Core
> Issue Type: New Feature
> Components: core, query-hql
> Environment: Hibernate 3.1 plus Annotations extending EJB3 implementation
> Reporter: James Salt
> Attachments: nestedset.tar.gz, utils-parent-20091117.tar.gz
>
> Original Estimate: 3 weeks
> Remaining Estimate: 3 weeks
>
> An enhancement to allow entities to exist in a managed tree (DAG) structure, via the use of property annotations and entity annotations. With an extension to the HQL language to mimic the Oracle recusive query clause.
> This would be classically be useful for Bill of Material uses, or any tree like entity structure.
> I have implemented a homebrew approach using the 'adjacency list method' , and a post persist call back method to set the node path. Although I think a more full blown optimised algorithm would be the 'modified preorder tree traversal algorithm'.
> In the annotations world this could be implemented using an annotation like @Hierarchical to the entity, with a @Parent (mask for @ManyToOne) annotation on the parent field/parameter and @Children (mask for @OneToMany) annotation on the list of children entities.
> Then a postupdate method could be implemented for the entity type, that recalculates the tree meta data -i.e. parent, left and right.
> I believe this would be a valuable extension (useful for many common data models) to the hibernate core product that could be exposed through annotations as I have discussed and the hbm.xml.
> The users of such a system would be aware of the performance implications on insert/update/delete, but gain a massive performance gain on querying a tree data model.
>
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-4717) JPQL select using object() syntax fails in some cases
by Maillefer Jean-David (JIRA)
JPQL select using object() syntax fails in some cases
-----------------------------------------------------
Key: HHH-4717
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4717
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.1
Environment: Postgresql 8.4
Reporter: Maillefer Jean-David
While the following JPQL queries works:
select d.id, d from Document d
select object(d) from Document d
This one doesn't:
select d.id, object(d) from Document d
Note that it's correct JPQL syntax.
Error log:
15:29:29,532 WARN [HqlParser] processEqualityExpression() : No expression to process!
15:29:30,485 ERROR [SessionFactoryImpl] Error in named query: findSddExportDocumentStatusByIdDEBUG
org.hibernate.hql.ast.QuerySyntaxException: unexpected token: , near line 1, column 12 [select d.id, object(d) from ch.etc.sit.data.Document d where d.id <= :id or 1 = 1]
at org.hibernate.hql.ast.QuerySyntaxException.convert(QuerySyntaxException.java:54)
at org.hibernate.hql.ast.QuerySyntaxException.convert(QuerySyntaxException.java:47)
at org.hibernate.hql.ast.ErrorCounter.throwQueryException(ErrorCounter.java:82)
at org.hibernate.hql.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:281)
at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:180)
at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:134)
at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:101)
at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:80)
at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:94)
at org.hibernate.impl.SessionFactoryImpl.checkNamedQueries(SessionFactoryImpl.java:436)
at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:384)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1327)
at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:867)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:669)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:132)
at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:301)
at sun.reflect.GeneratedMethodAccessor556.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
at org.jboss.system.ServiceController.start(ServiceController.java:460)
at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:362)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(Unknown Source)
at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
--
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, 6 months
[Hibernate-JIRA] Commented: (HHH-1575) Expression.in on component object gives parameters til SQL in wrong order
by Chris Wilson (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1575?page=c... ]
Chris Wilson commented on HHH-1575:
-----------------------------------
If anyone needs a workaround for this bug in Hibernate 3.3.2, you can download our fixed copy of the InExpression class here:
http://rita.wfplogistics.org/trac/browser/rita/src/org/wfp/rita/db/FixedI...
and then replace this code:
{code}
criteria.add(Restriction.in("id", ids));
{code}
with:
{code}
criteria.add(new FixedInExpression("id", ids));
{code}
> Expression.in on component object gives parameters til SQL in wrong order
> -------------------------------------------------------------------------
>
> Key: HHH-1575
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1575
> Project: Hibernate Core
> Issue Type: Bug
> Components: query-criteria
> Affects Versions: 3.1.2
> Environment: Oracle 9i, org.hibernate.criterion.InExpression
> Reporter: Thierry Hermann
> Fix For: 3.5
>
> Attachments: HibernateMultiColumnPrimaryKeyCriteriaTest.java
>
>
> The InExpression produces a statement like [where (key, station) in ((?,?),(?,?)...)] indeed.
> but the parameter binding is wrong.
> In fact if you look in org.hibernate.criterion.InExpression, getTypedValues() method (line: 53-54) both for loop should be inverted:
> for ( int i=0; i<types.length; i++ )
> for ( int j=0; j<values.length; j++ )
> should become:
> for ( int j=0; j<values.length; j++ )
> for ( int i=0; i<types.length; i++ )
--
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, 6 months