February 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-421) Exceptions happening in backend are unnoticed

by Sanne Grinovero (JIRA)

Exceptions happening in backend are unnoticed --------------------------------------------- Key: HSEARCH-421 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-421 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.1.1.GA, 3.1.0.GA Reporter: Sanne Grinovero Fix For: 3.2.0.Beta2 Any exception happening in the backend is not noticed as it happens in a separate thread. -- 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
27
0 / 0

[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-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

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: (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"/>  <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

3
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-443) Using a Field extending AbstractField causes a ClassCastException in DocumentBuilderIndexedEntity when using @AnalyzerDiscriminator

by Markus Horehled (JIRA)

Using a Field extending AbstractField causes a ClassCastException in DocumentBuilderIndexedEntity when using @AnalyzerDiscriminator ------------------------------------------------------------------------------------------------------------------------------------ Key: HSEARCH-443 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-443 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.2.0.Beta1 Reporter: Markus Horehled I use a @AnalyzerDiscriminator in order to return the name of an existing analyzer depending on the language out of my Analzyers defined in @AnalyzerDefs. Further on I use a custom Field extending AbstractField/implementing org.apache.lucene.document.Fieldable within a custom FieldBridge. On building the corresponding index I then do get a ClassCastException from ocumentBuilderIndexedEntity's allowAnalyzerDiscriminatorOverride() method because this method casts the document's fields retrieved with doc.getFields() to Field instead of Fieldable even though Fieldable interface implementing objects are only added to that list in Document! Thus Fieldable interface should rather be used here instead of Field. -- 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-453) FSSlaveDirectoryProvider: initial refresh

by Stephan Bublava (JIRA)

FSSlaveDirectoryProvider: initial refresh ----------------------------------------- Key: HSEARCH-453 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-453 Project: Hibernate Search Issue Type: Improvement Components: directory provider Affects Versions: 3.1.1.GA Reporter: Stephan Bublava Priority: Minor FSSlaveDirectoryProvider schedules the first refresh of the index files after the defined refresh period has elapsed. The first refresh should occur immediately. In other words: TimerTask task = new TriggerTask( sourceIndexDir, indexDir ); long period = DirectoryProviderHelper.getRefreshPeriod( properties, directoryProviderName ); timer.scheduleAtFixedRate( task, 0L, period ); instead of: TimerTask task = new TriggerTask( sourceIndexDir, indexDir ); long period = DirectoryProviderHelper.getRefreshPeriod( properties, directoryProviderName ); timer.scheduleAtFixedRate( task, period, period ); -- 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: (HSEARCH-446) how to install hibernate-search.zip in my project

by azael espinosa (JIRA)

how to install hibernate-search.zip in my project ------------------------------------------------- Key: HSEARCH-446 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-446 Project: Hibernate Search Issue Type: New Feature Affects Versions: 3.1.1.GA Environment: sqlserver, jboss-5.1.0.GA, jboss-seam-2.2.0.GA, ant 1.6. Reporter: azael espinosa I have this error 17:08:47,495 WARN [JDBCExceptionReporter] SQL Error: 102, SQLState: S0001 17:08:47,495 ERROR [JDBCExceptionReporter] Incorrect syntax near '-'. I recommend installing hibernate-search-3.1.1.GA, download the zip from hibernate and now do not know where or how to install it to avoid that error -- 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
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-462) Indexes are not getting updated when entity gets updated via hql.

by shareef shaik (JIRA)

Indexes are not getting updated when entity gets updated via hql. ----------------------------------------------------------------- Key: HSEARCH-462 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-462 Project: Hibernate Search Issue Type: Bug Affects Versions: 3.1.1.GA Environment: Hibernate 3.3, H-Search 3.1.1 GA, Hiberante Annotations, Oracle DB, FSDirectoryProvider Reporter: shareef shaik We are using Hibernate Annotations and Hibernate Search, and to my understanding there is no need to write listeners to update/delete index on update/delete of an entity. I tried updating an entity via hql update, and also via persisting the entity and making changes in it. In the second scenario, the index is getting updated, but in the first scenario it is not. I checked for the changes in db and in both scenarios, the changes are reflected in db. A simple test case for the same. Case 1: -------- String hql = "update UserMaster umst set umst.userName = :uName where umst.userId = :uId"; org.hibernate.Query query = getSession().createQuery(hql); query.setParameter("uName","ABM1"); query.setParameter("uId",1001L); query.executeUpdate(); Case 2: -------- UserMaster master = (UserMaster)getSession().get(UserMaster.class,1001L); master.setUserName("ABM1"); -- 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues February 2010