[Hibernate-JIRA] Created: (HSEARCH-396) disableFullTextFilter(String name) in FullTextQueryImpl does not disable the filter.
by wolfjourn (JIRA)
disableFullTextFilter(String name) in FullTextQueryImpl does not disable the filter.
------------------------------------------------------------------------------------
Key: HSEARCH-396
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-396
Project: Hibernate Search
Issue Type: Bug
Components: query
Affects Versions: 3.1.1.GA
Environment: Hibernate 3.3.2.GA
Hibernate Annotations 3.4.0.GA
RDBMS: MySQL, version: 5.0.70-log
JDBC driver: MySQL-AB JDBC Driver, version: mysql-connector-java-5.1.6
Reporter: wolfjourn
The disableFullTextFilter(String name) method in FullTextQueryImpl does not cause the filter to be disabled. This is due to incorrect logic in the buildFilters() method in the same class.
For example,
fullTextQuery = s.createFullTextQuery( query, Driver.class );
fullTextQuery.list().size(); /* Returns 10 */
fullTextQuery.enableFullTextFilter("security");
fullTextQuery.list().size(); /* Returns 5 */
fullTextQuery.disableFullTextFilter("security");
fullTextQuery.list().size(); /* Returns 5. Should return 10. */
Initially, buildFilters() constructs `filter' using the "security" filter from filterDefinitions. During the disableFullTextFilter("security") call, the filter is removed from `filterDefinitions'. However, `filter' remains intact. The subsequent call to buildFilters() returns immediately as `filterDefinitions' is now empty, leaving `filter' intact and thus not disabling the "security" filter. Furthermore, if a filter is disabled and replaced with another filter, the result will be a composition of both filters as towards the bottom of buildFilters(), any existing `filter' is chained onto the end of a new `chainedFilter'. This results in an empty result set if the sets returned by the filters are mutually exclusive.
It looks like this issue was resolved with revision 16755. However, this is still worth documenting here for other 3.1.1.GA users that might run into the same issue.
--
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
[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
[Hibernate-JIRA] Created: (HSEARCH-399) NPE in org.hibernate.search.backend.WorkQueue.clear()
by Dobes Vandermeer (JIRA)
NPE in org.hibernate.search.backend.WorkQueue.clear()
-----------------------------------------------------
Key: HSEARCH-399
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-399
Project: Hibernate Search
Issue Type: Bug
Affects Versions: 3.1.1.GA
Reporter: Dobes Vandermeer
Our server blew up, and we're seeing a continuous stream of:
[#|2009-09-17T06:24:02.169-0700|SEVERE|sun-appserver9.1|books.db.search.SafeBatchedQueueingProcessor|_ThreadID=40;_Threa
dName=httpSSLWorkerThread-8080-19;_RequestID=97e3df6c-2fc7-4f54-a47a-e77ba48d1a07;|RuntimeException during cancelWorks()
java.lang.NullPointerException
at org.hibernate.search.backend.WorkQueue.clear(WorkQueue.java:58)
at org.hibernate.search.backend.impl.BatchedQueueingProcessor.cancelWorks(BatchedQueueingProcessor.java:180)
at org.hibernate.search.backend.impl.PostTransactionWorkQueueSynchronization.afterCompletion(PostTransactionWorkQueueSynchronization.java:56)
at com.sun.enterprise.distributedtx.J2EETransaction.commit(J2EETransaction.java:491)
The method body for this is:
public void clear() {
queue.clear(); // <---- queue is null
if (sealedQueue != null) sealedQueue.clear();
}
It appears that queue may be set null by the setSealedQueue method above:
public void setSealedQueue(List<LuceneWork> sealedQueue) {
//invalidate the working queue for serializability
queue = null;
this.sealedQueue = sealedQueue;
}
The only change I've made recently that I thought could cause this was to change the search system to run in a separate thread. My hibernate search options are:
<exclude-unlisted-classes>true</exclude-unlisted-classes>
<properties>
<property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect"/>
<property name="hibernate.show_sql" value="false"/>
<property name="hibernate.cache.provider_class" value="net.sf.ehcache.hibernate.EhCacheProvider"/>
<property name="hibernate.cache.use_query_cache" value="true"/>
<property name="hibernate.cache.use_second_level_cache" value="true"/>
<property name="hibernate.bytecode.provider" value="javassist"/>
<property name="hibernate.search.default.directory_provider" value="org.hibernate.search.store.FSDirectoryProvider"/>
<property name="hibernate.search.default.indexBase" value="../search-indexes"/>
<property name="hibernate.search.worker.scope" value="books.db.search.SafeWorkerImpl"/>
<property name="hibernate.search.worker.backend" value="books.db.search.SafeBackendQueueProcessorFactory"/>
<property name="hibernate.search.worker.execution" value="async"/> <!-- sync or async -->
<property name="hibernate.search.worker.buffer_queue.max" value="5"/>
<property name="hibernate.search.worker.thread_pool.size" value="5"/>
</properties>
Note that books.db.search.Safe* are classes I wrote that wrap the default implementation with an exception handler; sometimes RuntimeExceptions were thrown and glassfish would just silently eat them and fail, now they are noisily eaten and the transaction commits anyway.
This was probably (to some degree) triggered by the exception logged just prior:
[#|2009-09-17T06:23:56.498-0700|SEVERE|sun-appserver9.1|org.hibernate.event.def.AbstractFlushingEventListener|_ThreadID=40;_ThreadName=httpSSLWorkerThread-8080-19;_RequestID=97e3df6c-2fc7-4f54-a47a-e77ba48d1a07;|Could not synchronize database state with session
org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [books.db.Business#5617057]
at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1782)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2425)
at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2325)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2625)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:115)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279)
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:321)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1028)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:366)
at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:504)
at com.sun.enterprise.distributedtx.J2EETransaction.commit(J2EETransaction.java:419)
Figuring out under which conditions the queue became null but shouldn't have been might be nearly impossible at this point, although I'll watch out for repeats of this issue.
The NPE itself might be easier to fix, if you just check for null before calling clear().
For now I'll try implementing a workaround in my safe subclass like this:
@Override
public void cancelWorks(WorkQueue workQueue) {
try {
super.cancelWorks(workQueue);
} catch (RuntimeException e) {
logger.error("RuntimeException during cancelWorks()", e);
try {
if(workQueue.getQueue() != null)
workQueue.getQueue().clear();
else
workQueue.getSealedQueue().clear();
} catch(org.hibernate.annotations.common.AssertionFailure t) {
// sealedQueue was null too
}
}
}
--
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
[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
[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
[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
[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