July 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-351) Index fields on subclasses of a field marked @IndexEmbedded

by Dimas Guardado, Jr. (JIRA)

Index fields on subclasses of a field marked @IndexEmbedded ----------------------------------------------------------- Key: HSEARCH-351 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-351 Project: Hibernate Search Issue Type: Improvement Affects Versions: 3.1.0.GA Reporter: Dimas Guardado, Jr. the fields of the subclasses of a property marked with @IndexedEmbedded are not getting indexed, but the fields of the base class are. I discussed this issue previously on the forums, and I was directed to file a JIRA issue for it. For more context and a code example to illustrate the problem, please see the following forum thread: http://forum.hibernate.org/viewtopic.php?p=2404209#2404209 -- 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

16 years

4
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-387) Disable the automatic indexing as per session basis

by Behrang Javaherian (JIRA)

Disable the automatic indexing as per session basis --------------------------------------------------- Key: HSEARCH-387 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-387 Project: Hibernate Search Issue Type: New Feature Components: engine Affects Versions: 3.1.1.GA Reporter: Behrang Javaherian We are using the hibernate search and automatic indexing to index our model objects. The issue that we got is that anytime we touch a domain model and save the object, hibernate search is updating the underlying indexes and since our model objects are big it is time consuming. The are many cases that we know that the index doesn't need to be updated ( Like someone is just attaching an image to an article, etc). Is it possible to provide some sort of functionality to disable the automatic re-indexing per session. Thanks Behrang Javaherian http://www.beyondng.com -- 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

16 years

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-389) Filtering using criteria API is unreliable

by Dirk Mahler (JIRA)

Filtering using criteria API is unreliable ------------------------------------------ Key: HSEARCH-389 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-389 Project: Hibernate Search Issue Type: Bug Components: query Affects Versions: 3.1.1.GA, 3.1.0.GA Environment: Hibernate 3.3.2.GA, Hibernate Entity Manager 3.4.0.GA, Oracle 9.2 Reporter: Dirk Mahler Within one EntityManager session the following use case leads to wrong results if using Hibernate Search in combination with the Criteria API: 1. Execute a simple query which returns Entity A and B as results 2. Doing a full text query which will find A and B but restricts the results to A by doing a further filtering for an attribute which is only satisfied by A using the criteria API. Hibernate Search returns both A and B. After looking at the source code the reason seems to be the follwoing: - the full text search returns a list of entities - the Criteria query is simply used to initialize the entities within the EntityManager's session, the result set/list itself is ignored, see ObjectLoaderHelper#initializeObjects(EntityInfo[] entityInfos, Criteria criteria, Class<?> entityType, SearchFactoryImplementor searchFactoryImplementor): ... criteria.add( disjunction ); criteria.list(); //load all objects <-- ??? } - the result is now determined by checking wether the entities from the full text search are initialized using Hibernate.isInitalized(), see QueryLoader#load(EntityInfo... entityInfos and returnAlreadyLoadedObjectsInCorrectOrder(EntityInfo[] entityInfos, Session session)) This approach is highly fragile because it relies on side effects and should be discarded in favor of using the result of the criteria query which already represents the expected result. Is there any good reason to ignore it? -- 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

16 years

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3997) Configure the maven javadoc plugin

by Steve Ebersole (JIRA)

Configure the maven javadoc plugin ---------------------------------- Key: HHH-3997 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3997 Project: Hibernate Core Issue Type: Task Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.3.x, 3.5 So far we have been just accepting the defaults. We need to start applying our customizations. -- 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

16 years

1
8
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-385) Lazy ManyToOne association with @containedIn annotation cause HSearch create entity index with documentId = 0

by Grégoire Rolland (JIRA)

Lazy ManyToOne association with @containedIn annotation cause HSearch create entity index with documentId = 0 ------------------------------------------------------------------------------------------------------------- Key: HSEARCH-385 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-385 Project: Hibernate Search Issue Type: Bug Affects Versions: 3.1.1.GA, 3.1.0.GA Environment: Hibernate 3.3.1.GA, Postgresql 8.3 Reporter: Grégoire Rolland Priority: Critical Attachments: hsearch.tar.gz In a transaction, create Entity1 associated to one Entity2 (E1->E2 lazy oneToMany, E2->E1 lazy manyToOne). In antoher transaction, find Entity2, modify Entity2. On commit, I get this log : 2009-07-02 11:42:18,791 TRACE [org.hibernate.search.backend.impl.lucene.works.DeleteExtWorkDelegate] - Removing class org.foo.hibernate.search.jira.Entity1#0 by id using an IndexWriter. 2009-07-02 11:42:18,792 TRACE [org.hibernate.search.backend.impl.lucene.works.AddWorkDelegate] - add to Lucene index: class org.foo.hibernate.search.jira.Entity1#0:Document<stored/uncompressed,indexed<_hibernate_class:org.foo.hibernate.search.jira.Entity1> stored/uncompressed,indexed<uid:0> stored/uncompressed,indexed<entities2.uid:224136060>> in the index : 1 document for Entity, with the correct Id, and 1 document with Id = 0, index is corrupted. See the test case for more info. -- 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

16 years

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3449) Unable to use Oracle stored procedure in a <sql-query>

by RC (JIRA)

Unable to use Oracle stored procedure in a <sql-query> ------------------------------------------------------ Key: HHH-3449 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3449 Project: Hibernate3 Issue Type: Bug Components: query-sql Affects Versions: 3.2.6 Environment: Hibernate 3.2.6GA Oracle 10.2.0.4 (& Oracle JDBC Driver version - 11.1.0.6.0) Java 1.6.0_06 Reporter: RC Using a stored procedure to fetch result set. However, an IllegalAccessException is thrown: Caused by: org.hibernate.HibernateException: Problem while trying to load or access OracleTypes.CURSOR value at org.hibernate.dialect.Oracle8iDialect.registerResultSetOutParameter(Oracle8iDialect.java:371) at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1560) at org.hibernate.loader.Loader.doQuery(Loader.java:673) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236) at org.hibernate.loader.Loader.doList(Loader.java:2213) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104) at org.hibernate.loader.Loader.list(Loader.java:2099) at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:289) at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1695) at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142) at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:152) at org.hibernate.impl.AbstractQueryImpl.uniqueResult(AbstractQueryImpl.java:811) .... Caused by: java.lang.IllegalAccessException: Class org.hibernate.dialect.Oracle8iDialect can not access a member of class oracle.jdbc.driver.OracleTypes with modifiers "" at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65) at java.lang.Class.newInstance0(Class.java:349) at java.lang.Class.newInstance(Class.java:308) at org.hibernate.dialect.Oracle8iDialect.registerResultSetOutParameter(Oracle8iDialect.java:369) ... 35 more -- 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

16 years

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3395) Oracle LONG datatype fetching fails on superclass Criteria query

by Ville Anttonen (JIRA)

Oracle LONG datatype fetching fails on superclass Criteria query ---------------------------------------------------------------- Key: HHH-3395 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3395 Project: Hibernate3 Issue Type: Bug Environment: Oracle 10 Windows XP Hibernate 3 Weblogic 9.2 Reporter: Ville Anttonen I have dao-layer method like this. public PersistentQuery getPersistentQuery(String userId, long queryId){ .... Criteria criteria = m_session.createCriteria(PersistentQuery.class); criteria.add(Expression.eq("userId",userId)); criteria.add(Expression.eq("id",new Long(queryId))); return (PersistentQuery) criteria.uniqueResult(); ..... } Previous code throws "Stream already closed" exception. PersistentQuery is abstract class and it's subclasses contains UserType - field that wraps Oracle's long varchar field. I can fix this by creating criteria by subclass like " Criteria criteria = m_session.createCriteria(PersistentOrganizationQuery.class); ". We're migrating from ingres -> oracle and in ingres previous implementation worked fine. -- 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

16 years

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4026) one-to-one non-lazy loading but Filters Not Applied.

by Sandeep Vaid (JIRA)

one-to-one non-lazy loading but Filters Not Applied. ---------------------------------------------------- Key: HHH-4026 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4026 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.3.2, 3.3.1, 3.3.0.SP1, 3.3.0.GA, 3.3.0.CR2, 3.3.0.CR1, 3.2.7, 3.2.6 Environment: Hibernate 3.2.6 Reporter: Sandeep Vaid Attachments: EntityJoinWalker.java While fetching one-to-one association, filters are not applied. I have modified the hibernate code to resolve this issue. With these changes, if filters a are enabled for one-to-one associations, they will be applied (appear in sql) else not. Changes Done: A) In EntityJoinWalker.java >> constructor:line 40 Current Code: StringBuffer whereCondition = whereString( getAlias(), uniqueKey, batchSize ) //include the discriminator and class-level where, but not filters .append( persister.filterFragment( getAlias(), Collections.EMPTY_MAP ) ); Changed Code: StringBuffer whereCondition = whereString( getAlias(), uniqueKey, batchSize ); //include the discriminator and class-level where, but not filters String filter= persister.filterFragment( getAlias(), enabledFilters); whereCondition.insert( 0, StringHelper.moveAndToBeginning(filter) ); -- 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

16 years

3
11
0 / 0

[Hibernate-JIRA] Created: (HHH-3406) IndexOutOfBoundsException when a flush occurs during validation inside a flush

by vincent Larchet (JIRA)

IndexOutOfBoundsException when a flush occurs during validation inside a flush ------------------------------------------------------------------------------ Key: HHH-3406 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3406 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.6 Environment: 3.2.6ga, oracle11g, tomcat 6.0.16, spring 2.5.1, redhat5.2 or windows XP or debian etch Reporter: vincent Larchet Say we have entity A: @Entity public class A { [...] @AssertTrue public boolean validateSomeCondition(){ //call service S B=S.loadEntityB() [.... do some stuff with B...] } } In my hibernate session I modifiy several entities among them A1, A2, A3 (instances of A), then I flush the session that firsts validates A1. Inside A1.validateSomeCondition() I have to call a service that loads some data inside its own transaction, thus when it returns a commit is triggered that is intercepted an hibernate flushes its session, and not only entities bound to this transaction but the WHOLE session (including A2, A3 !!!). Then validation of A1 finishes successfully and A1 is saved to db, but right after that this exception occurs java.lang.IndexOutOfBoundsException: Index: 1, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:168) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at org.springframework.orm.hibernate3.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:596) at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709) at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678) at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:319) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) [...] I do not really know if flushing A2,A3 entites inside the 2nd flush is an issue or not (I do not mind actually...), so I suggest this quick fix: inside ActionQueue method private void executeActions(List list) throws HibernateException { int size = list.size(); for(int i = 0; i < size; i++) execute((Executable)list.get(i)); list.clear(); session.getBatcher().executeBatch(); } replace the "static" int size = list.size(); for(int i = 0; i < size; i++) by an iterator... thx vincent NB: we use OpenSessionInViewFilter -- 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

16 years

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-379) Properly implement new JPA 2 methods (Query and EntityManager)

by Emmanuel Bernard (JIRA)

Properly implement new JPA 2 methods (Query and EntityManager) -------------------------------------------------------------- Key: HSEARCH-379 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-379 Project: Hibernate Search Issue Type: New Feature Reporter: Emmanuel Bernard -- 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

16 years

1
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues July 2009