May 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-52) Ability to load more efficiently an object graph from a lucene query by customizing the fetch modes

by Emmanuel Bernard (JIRA)

Ability to load more efficiently an object graph from a lucene query by customizing the fetch modes --------------------------------------------------------------------------------------------------- Key: HSEARCH-52 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-52 Project: Hibernate Search Issue Type: New Feature Components: query Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Fix For: 3.0.0.beta2 ftQuery.setCriteria(criteria) The criteria can override the fetch modes, nothing beyond that is supported. -- 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

17 years, 7 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-48) NullPointerException when Query.list()

by Eddie Man (JIRA)

NullPointerException when Query.list() -------------------------------------- Key: HSEARCH-48 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-48 Project: Hibernate Search Issue Type: Bug Components: query Environment: Linux, Oracle/MySQL Reporter: Eddie Man Priority: Critical Attachments: screenshot21.png Suppose I have the following mapping: ClassA ======= <class name="ClassA" table="TableA" lazy="false"> <id name="ID" column="ID" type="integer" unsaved-value="0"> <generator class="native"> </generator> </id> <one-to-one name="classB" class="ClassB" cascade="save-update,lock" property-ref="classA" lazy="no-proxy" access="field"/> </class> ClassB ======= <class name="ClassB" table="TableB" lazy="false"> <composite-id> <key-property name="ID" column="ID" type="integer"/> <key-many-to-one name="classA" column="ClassAID" class="ClassA"> </key-many-to-one> </composite-id> </class> Pre-condition : TableA +----+ | ID | +----+ | 1 | +----+ TableB +----+----------+ | ID | ClassAID | +----+----------+ | 1 | 1 | +----+----------+ When I use Session.createQuery("From ClassA as ClassA").list(), it throw the following exception: java.lang.NullPointerException at org.hibernate.persister.entity.AbstractEntityPersister.loadByUniqueKey(AbstractEntityPersister.java:1641) at org.hibernate.type.EntityType.loadByUniqueKey(EntityType.java:608) at org.hibernate.type.EntityType.resolve(EntityType.java:382) at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:116) at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:842) at org.hibernate.loader.Loader.doQuery(Loader.java:717) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224) at org.hibernate.loader.Loader.doList(Loader.java:2211) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2095) at org.hibernate.loader.Loader.list(Loader.java:2090) at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:375) at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338) at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1123) at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79) -- 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

17 years, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-51) Optimization: Use a query rather than batch-size to load objects when a single entity (hierarchy) is expected

by Emmanuel Bernard (JIRA)

Optimization: Use a query rather than batch-size to load objects when a single entity (hierarchy) is expected ------------------------------------------------------------------------------------------------------------- Key: HSEARCH-51 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-51 Project: Hibernate Search Issue Type: Improvement Affects Versions: 3.0.0.beta1 Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Fix For: 3.0.0.beta2 Use where id in (...) rather than the load() then initialize approach -- 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

17 years, 7 months

1
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-785) Persistence through cascading should have higher precedence than orphan-delete

by Joe Kelly (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-785?page=co... ] Joe Kelly commented on HHH-785: ------------------------------- I realize this issue is closed but I wanted to put in my two cents. I totally agree with Christian's argument: persistence through cascading should indeed have higher precedence than orphan-delete. As Christian says, without this feature, you must resort to complex session coding to relocate a node. Christian's code example seems to be the most natural and transparent way to relocate a node, but it doesn't work, of course: a.remove(b); c.add(b); session.flush(); The following code works but seems less natural and transparent, in my opinion: b.setParent(c); session.flush(); session.refresh(a); session.refresh(c); > Persistence through cascading should have higher precedence than orphan-delete > ------------------------------------------------------------------------------ > > Key: HHH-785 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-785 > Project: Hibernate3 > Issue Type: Improvement > Components: core > Affects Versions: 3.1 beta 1 > Reporter: Christian Bauer > > A typical tree mapped using an adjacency list: > <many-to-one name="parent" cascade="none"/> > <set name="children" cascade="all, delete-orphan"/> > A normal tree operation is moving a node: > a.remove(b); > c.add(b); > This results in an exception, as Hibernate currently rates the delete-orphan as more important and warns that the node would become persistent again through cascading. However, this is the only way to implement relocation of a node in a tree without resorting to complex session coding. I argue that the "delete orphans" guarantee given in the mapping should not have precedence over the the actual non-orphaned persistent state in the Session. -- 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

17 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-952) Patch to allow subqueries with joins using Criteria API and Subqueries with DetachedCriteria

by Don Mitchell (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-952?page=co... ] Don Mitchell commented on HHH-952: ---------------------------------- Why is the "subquery" variable declared as a DetachedCriteria? Fyi...in all of my uses of this (which are similar to what you are attempting) I create a regular Criteria from the Session and then add a DetachedCriteria for the exists clause. I never use two detachedCriterias together. Criteria criteria = session.createCriteria(User.class, "user"); DetachedCriteria dc = DetachedCriteria.forClass("Organization.class, "org") .setProjection(Property.forName("id")) .add(Restrictions.eqProperty("user.id", "org.user_id"); criteria.add(Subqueries.exists(dc)); Fyi...the code above isn't cut-n-pasted. My cases are a little uglier and I have a lot of constants defined, but I think the above is basically correct. Good luck...let me know if the JOIN is the issue. . > Patch to allow subqueries with joins using Criteria API and Subqueries with DetachedCriteria > -------------------------------------------------------------------------------------------- > > Key: HHH-952 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-952 > Project: Hibernate3 > Issue Type: Patch > Components: core > Affects Versions: 3.1 beta 1, 3.1 beta 2 > Environment: 3.1beta1 with MS SQL 2000 via jTDS > Reporter: John > Priority: Critical > Attachments: subquery-patch-311.txt, subquery-patch-313.txt, subquery-patch-31beta3.txt, subquery-patch.txt, subquery-patch.txt, SubqueryExpression.java > > > The existing code in SubqueryExpression.java constructed a select statement but did not have any provisions for creating joins. Therefore, it was not possible using the criteria API to create an exists subselect that had a join, even though running the source DetachedCriteria alone works perfectly. > For example, if this is the goal: > select * from foo f > where exists (select id from bar b join other o on b.o_id = o.id where o.prop = '123' and b.foo_id = f.id) > One might try something like this: > Criteria crit = session.createCriteria(Foo.class, fooAlias); > DetachedCriteria barCrit = DetachedCriteria.forClass(Bar.class, barAlias); > DetachedCriteria otherCrit = barCrit.createCriteria(Bar.OTHER_JOIN); > otherCrit.add( Restrictions.eq(Other.PROP, "123") ); > barCrit.add( Restrictions.eqProperty( -- props to join to foo here --) ); > barCrit.setProjection( Projections.id() ); > crit.add( Subqueries.exists(barCrit) ); > However, the existing code generates something like the following, which gets an error with an unknown alias 'o': > select * from foo f > where exists (select id from bar b where o.prop = '123' and b.foo_id = f.id) > This is also described here (at the end): http://forum.hibernate.org/viewtopic.php?t=942488 > The patch to SubqueryExpression.java fixes this to included the joins necessary for the filtering. This code was modeled (copied) off of code from CriteriaLoader. For me this works perfectly, but I don't understand the internals of this stuff enough to say how robust it is. Also included is a patch to the test case to enable testing of this, which was present but commented out. I did not change the contents of the test, which currently only attempts a joined subquery. This used to fail with an error, but now it works. The test does not check the results at all. (Inconsequential to the patch - Enrollment has two Ls.) > -----side notes > The patch file also has two other patches. The first increases the delay in BulkManipulationTest because I was getting inconsistent test results. I think that the precision on the version timestamp is not enough for 300 milliseconds delay to be enough to guarantee the test results. Also, in build.xml, there was a line that was meant to exclude the performance tests, but there was no **/*, on *, so they actually were not excluded. I changed this so the tests would complete in a reasonable amount of time. However, there is one other issue with testing that I worked around manually. After each test run, two databases (Users and Email) were left in the database. If I did not manually delete these then the number of failures on the next test run was different. This was really confusing until I figured it out because I was trying to make sure all the other testcases still passed with my patch, but even without the patch I was getting different results. -- 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

17 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1423) ParameterParser bug - ordinal parameter mismatch

by Vadim Berezniker (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1423?page=c... ] Vadim Berezniker commented on HHH-1423: --------------------------------------- I hit this issue today. I'm trying to sort by a column that contains the string "call". I can't even think of how I can work around this issue. > ParameterParser bug - ordinal parameter mismatch > ------------------------------------------------- > > Key: HHH-1423 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1423 > Project: Hibernate3 > Issue Type: Bug > Components: query-hql > Affects Versions: 3.1.2 > Environment: Windows XP SP2, JDK 1.5.0_06-b05, Spring 1.2.6, antlr-2.7.6rc1 > Reporter: Artur Wronski > Priority: Critical > Attachments: HHH1423Test.java, ParameterParser.2.patch, ParameterParser.3.patch, ParameterParser.patch, RecognizerBug.java > > > There is still problem with ParameterParser. The same was in Hibernate 3.1.1 > Runnable TestCase in attachment. -- 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

17 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-4) Be able to use a Lucene Sort er on queries

by Emmanuel Bernard (JIRA)

Be able to use a Lucene Sort er on queries ------------------------------------------ Key: HSEARCH-4 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-4 Project: Hibernate Search Type: New Feature Components: query Reporter: Emmanuel Bernard Assigned to: Emmanuel Bernard Fix For: FIRST -- 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

17 years, 7 months

4
15
0 / 0

[Hibernate-JIRA] Created: (HHH-2612) Null foreign key results in Transient Object Exception

by maxtor (JIRA)

Null foreign key results in Transient Object Exception ------------------------------------------------------ Key: HHH-2612 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2612 Project: Hibernate3 Issue Type: Bug Components: query-hql Environment: Hibernate version 3.2 cr3, Oracle 8i Reporter: maxtor Priority: Blocker Two tables A and B where B is parent table and the relation between A and B is unidirectional many-to-one. mapping for A: <hibernate-mapping package="parms"> <class name="A" table="A" lazy="true" batch-size="20" select-before-update='true' > <id name="id" column="ID"> <generator class="increment"/> </id> <many-to-one name="b" column="Ba_ID" class="B" not-found="ignore" cascade="none" lazy="false" not-null="false" unique="false" /> <property name="place" column="PLACE"/> </class> mapping for B: <class name="B" table="B" lazy="true" batch-size="10" select-before-update="true"> <cache usage="read-write"/> <id name="id" column="B_ID" > <generator class="assigned"/> </id> <property name="programId" column="GROUP_ID" unique="true"/> </class> Also some of rows of table A have null values for column Ba_ID. Now retrieval of these rows which have null values for column Ba_ID works fine. And it retrieves a null relationship between the tables for these rows. Now when I try to update column PLACE. It tries to update column Ba_ID also and there it throws a TransientOBjectException. But nothing is being changed for that column. Also cascade is set to "none". Transaction scope code A a=_form.getA(id); a.setPlace("place"); sess.saveOrUpdate(a); tx.commit(); sess.close(); And the last SQL statement being tried to be executed is: UPDATE A set ......(all columns )..... where ID =? And the exception thrown is: [ERROR] AbstractFlushingEventListener - -Could not synchronize database state with session <org.hibernate.TransientObjectException: B> at org.hibernate.engine.ForeignKeys.getEntityIdentifierIfNotUnsaved(ForeignKeys.java:219) -- 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

17 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-50) Null Booleans lead to NPE

by Emmanuel Bernard (JIRA)

Null Booleans lead to NPE ------------------------- Key: HSEARCH-50 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-50 Project: Hibernate Search Issue Type: Bug Components: mapping Affects Versions: 3.0.0.beta1 Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Fix For: 3.0.0.beta2 -- 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

17 years, 7 months

1
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-952) Patch to allow subqueries with joins using Criteria API and Subqueries with DetachedCriteria

by Matthias Bayer (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-952?page=co... ] Matthias Bayer commented on HHH-952: ------------------------------------ here the example code for my comment ([10/May/07 03:14 PM ]): Example Code HibernateUtil.getCurrentSession().beginTransaction(); //subquery DetachedCriteria subquery = DetachedCriteria.forClass(MyClass.class, "MyClass"); subquery.setProjection(Projections.projectionList().add( Projections.property("MyClass.d"); //exists condition DetachedCriteria dc = DetachedCriteria.forClass(ClassB.class); dc = dc.setProjection(Property.forName("d"); dc.add(Property.forName("d").eqProperty( "MyClass.d")); dc.add(Restrictions.in("a",new String[] {"12345", "6789"})); dc.add(Restrictions.in("b", new String[] {"456"})); Criterion crit = Subqueries.exists(dc); subquery.add(crit); Criteria criteria = subquery.getExecutableCriteria(HibernateUtil.getCurrentSession()); criteria.list(); workaround: use an alias for ClassB and it works well. > Patch to allow subqueries with joins using Criteria API and Subqueries with DetachedCriteria > -------------------------------------------------------------------------------------------- > > Key: HHH-952 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-952 > Project: Hibernate3 > Issue Type: Patch > Components: core > Affects Versions: 3.1 beta 1, 3.1 beta 2 > Environment: 3.1beta1 with MS SQL 2000 via jTDS > Reporter: John > Priority: Critical > Attachments: subquery-patch-311.txt, subquery-patch-313.txt, subquery-patch-31beta3.txt, subquery-patch.txt, subquery-patch.txt, SubqueryExpression.java > > > The existing code in SubqueryExpression.java constructed a select statement but did not have any provisions for creating joins. Therefore, it was not possible using the criteria API to create an exists subselect that had a join, even though running the source DetachedCriteria alone works perfectly. > For example, if this is the goal: > select * from foo f > where exists (select id from bar b join other o on b.o_id = o.id where o.prop = '123' and b.foo_id = f.id) > One might try something like this: > Criteria crit = session.createCriteria(Foo.class, fooAlias); > DetachedCriteria barCrit = DetachedCriteria.forClass(Bar.class, barAlias); > DetachedCriteria otherCrit = barCrit.createCriteria(Bar.OTHER_JOIN); > otherCrit.add( Restrictions.eq(Other.PROP, "123") ); > barCrit.add( Restrictions.eqProperty( -- props to join to foo here --) ); > barCrit.setProjection( Projections.id() ); > crit.add( Subqueries.exists(barCrit) ); > However, the existing code generates something like the following, which gets an error with an unknown alias 'o': > select * from foo f > where exists (select id from bar b where o.prop = '123' and b.foo_id = f.id) > This is also described here (at the end): http://forum.hibernate.org/viewtopic.php?t=942488 > The patch to SubqueryExpression.java fixes this to included the joins necessary for the filtering. This code was modeled (copied) off of code from CriteriaLoader. For me this works perfectly, but I don't understand the internals of this stuff enough to say how robust it is. Also included is a patch to the test case to enable testing of this, which was present but commented out. I did not change the contents of the test, which currently only attempts a joined subquery. This used to fail with an error, but now it works. The test does not check the results at all. (Inconsequential to the patch - Enrollment has two Ls.) > -----side notes > The patch file also has two other patches. The first increases the delay in BulkManipulationTest because I was getting inconsistent test results. I think that the precision on the version timestamp is not enough for 300 milliseconds delay to be enough to guarantee the test results. Also, in build.xml, there was a line that was meant to exclude the performance tests, but there was no **/*, on *, so they actually were not excluded. I changed this so the tests would complete in a reasonable amount of time. However, there is one other issue with testing that I worked around manually. After each test run, two databases (Users and Email) were left in the database. If I did not manually delete these then the number of failures on the next test run was different. This was really confusing until I figured it out because I was trying to make sure all the other testcases still passed with my patch, but even without the patch I was getting different results. -- 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

17 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues May 2007