August 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-753) fullTextQuery.getResultList().size() != fullTextQuery.getResultSize() when using criteria

by Mathieu Perez (JIRA)

fullTextQuery.getResultList().size() != fullTextQuery.getResultSize() when using criteria ----------------------------------------------------------------------------------------- Key: HSEARCH-753 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-753 Project: Hibernate Search Issue Type: Bug Components: query Affects Versions: 3.4.0.Final Environment: hibernate 3.6.4.Final / postgresSQL Reporter: Mathieu Perez 1) My indexes are up-to-date and optimised 2) I'm aware about this part of documentation: "Like Google, the number of results is approximative if the index is not fully up-to-date with the database (asynchronous cluster for example)." 3) Two types of queries: 3.1) Query with "keyword" (or "below"/"above"/"fromTo") {code} QueryBuilder qb = fullTextSession.getSearchFactory().buildQueryBuilder().forEntity( Book.class ).get(); org.apache.lucene.search.Query query = qb .keyword() .onFields("title", "subtitle", "authors.name", "publicationDate") .matching("Java rocks!"); .createQuery(); {code} In this case, I don't meet any problem: query.getResultSize() == query.getResultList().size() 3.2) Query with criteria {code} Criteria criteria = s.createCriteria( Book.class ).createCriteria('isbn').add(Restrictions.like('XXXXXX')) Query q = s.createFullTextQuery( luceneQuery ).setCriteriaQuery( criteria ); {code} In this case, the result is different: {code} query.getResultSize() != query.getResultList().size() {code} Actually, query.getResultSize() exactly returns the number of Book contained in my Book's table. (select count(*) from Book;) without taking in consideration my criteria. I don't known if it's really a bug either it's the expected behaviour. When inspecting the org.hibernate.search.query.engine.impl.HSQueryImpl java class, I realized that {code} QueryHits queryHits = getQueryHits( searcher, 0 ) : {code} - 3.1) Takes in charge my keyword - 3.2) Doesn't seem to use my criteria -- 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, 7 months

4
15
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-783) Upgrade to Lucene 3.3

by Sanne Grinovero (JIRA)

Upgrade to Lucene 3.3 --------------------- Key: HSEARCH-783 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-783 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.0.0.Alpha1 It seems that we'll have to skip Lucene 3.2 as 3.3 is almost ready, and has the good news that no changes are required. -- 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, 7 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-6571) Criteria API generating wrong SQL for IN clause

by shay (JIRA)

Criteria API generating wrong SQL for IN clause ----------------------------------------------- Key: HHH-6571 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6571 Project: Hibernate Core Issue Type: Bug Components: core, entity-manager, metamodel Affects Versions: 3.6.6 Environment: hibernate entity manager 3.6.6.Final(using maven), ubuntu 11, Reporter: shay when using the code below to generate a query public Predicate toPredicate(Root<Project> root, CriteriaQuery<?> query, CriteriaBuilder builder) { static Integer[] ids = { 5183, 6036, 2270} Path<Long> id = root.get(Project_.Id); return builder.in(id).in((Object[]) ids).not(); } it comes out as : select generatedAlias0 from Project as generatedAlias0 where generatedAlias0.Id in () not in (5183, 6036, 2270) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-758) create DirectoryManager to handle different I/O aspects of an index

by Sanne Grinovero (JIRA)

create DirectoryManager to handle different I/O aspects of an index ------------------------------------------------------------------- Key: HSEARCH-758 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-758 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Fix For: 4.0.0.Alpha1 Near-Real-Time Lucene usage requires a coupling between the indexwriter and the indexreaders being used for searches. Also to make other features simpler we need to manage indexwriters and indexreaders in a more integrated form (Infinispan). refactor : DirectoryProvider * make a "DirectoryManager" instead, which is able to provide factories for both IndexReader an IndexWriters * add utility methods like "getName()" o (wish I had that in some cases to provide better error messages) * Instead of trying to foresee all needed methods, the extension point should not be the DirectoryManager interface directly, but have people plug in different aspects. * This is needed to eventually support: o Instantiated indexes - HSEARCH-336 o make good use of all new so called "Near-Real-Time" Lucene improvements by having IndexReader and IndexWriter possibly generated by the same service o reuse the JGroups channel used by the Infinispan Directory as transport for a backend (again, the two components need to interact) -- 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, 7 months

1
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-823) Make it possible to plug in custom IndexManager implementations

by Sanne Grinovero (JIRA)

Make it possible to plug in custom IndexManager implementations --------------------------------------------------------------- Key: HSEARCH-823 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-823 Project: Hibernate Search Issue Type: New Feature Components: directory provider Reporter: Sanne Grinovero Fix For: 4.0.0.Alpha1 See also {code}org.hibernate.search.indexes.impl.IndexManagerHolder.createDirectoryManager(String, Properties, Class<?>, WorkerBuildContext){code} to get started with this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-855) Classes extending BackendQueueProcessor are badly named XYZBackendQueueProcessorFactory

by Hardy Ferentschik (JIRA)

Classes extending BackendQueueProcessor are badly named XYZBackendQueueProcessorFactory --------------------------------------------------------------------------------------- Key: HSEARCH-855 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-855 Project: Hibernate Search Issue Type: Improvement Components: documentation, engine Reporter: Hardy Ferentschik Fix For: 4.0.0.Alpha2 See GitHub commit note - https://github.com/Sanne/hibernate-search/commit/44e50d4a8234fd3e96f0ae38... {quote} Haven't really looked at this code for some time, so I have a little bit of a beginner mind. Why is this thing called 'Factory'. Either the class or the interface is not named correctly. Should the interface maybe be BackendQueueProcessorFactory? We have a whole bunch of XYZBackendQueueProcessor, but they are now Runnables. Looking at BackendQueueProcessor I would say this name is correct, but the implementing classes should drop the 'Factory'. The current XYZBackendQueueProcessor classes could become XYZBackendQueueProcessorTask. WDYT? {quote} {quote} right, that's a long standing issue, I agree with that and actually it confuses me often. Very legacy names, I didn't really want at this point to rename everything so that - assuming you all knew this code a bit - recognizing old friends would have been easier. I've changed so much already. So, with the old design this was a Runnable Factory, as it returned Runnable instances, but now it still creates and uses Runnables, but this isn't exposed anymore so I like the interface name as it does a good job in representing the Processor. WDYT of changing the classname of all *ProcessorFactory to *Processor ? (i.e. this affects JMS, JGroups, etc...) Mind you, this affects end users using FQC names so if you agree in doing it (I'm all for it) I think we should track it both on JIRA and on the migration guide. {quote} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-759) provice Near-Real-Time Lucene updates

by Sanne Grinovero (JIRA)

provice Near-Real-Time Lucene updates ------------------------------------- Key: HSEARCH-759 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-759 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Fix For: 4.0.0.Alpha1 we actually already have "near real time" updates, but we can improve performance of it using the feature in Lucene which is referred to as the "Near-Real-Time" patch as it provides great improvements in our main use case. -- 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, 7 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-6599) Hibernate mark as rollback even for no transaction requests

by Alessandro Lazarotti (JIRA)

Hibernate mark as rollback even for no transaction requests ----------------------------------------------------------- Key: HHH-6599 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6599 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.6.7 Reporter: Alessandro Lazarotti When used a Hibernate EntityManager in a CMT Bean and a GenericJDBCException is launched, Hibernate will try a rollback even if there is not an active transaction, generating the exception: <org.hibernate.ejb.AbstractEntityManagerImpl> Unable to mark for rollback on PersistenceException: java.lang.IllegalStateException: [com.arjuna.ats.internal.jta.transaction.arjunacore.nosuchtx] [com.arjuna.ats.internal.jta.transaction.arjunacore.nosuchtx] No such transaction! at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.setRollbackOnly(BaseTransaction.java:188) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.setRollbackOnly(BaseTransactionManagerDelegate.java:135) at org.hibernate.ejb.AbstractEntityManagerImpl.markAsRollback(AbstractEntityManagerImpl.java:440) at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:595) at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:637) at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:74) ... hiding the original "Caused By" from the other Exception (GenericJDBCException). As example, a case where some error in runtime happens in a database procedure execution and the bean method is annotated as "NOT_SUPPORTED" transaction, this behaviour will happen and the original exception will be lost, the root exception is overridden by "No such transaction" exception and so the cause is not reported in log files. Hibernate should not try a rollback if there is not a transaction. Fixing it is necessary update the method: "protected void markAsRollback()" .. from org.hibernate.ejb.AbstractEntityManagerImpl.java That method just check no CMT JTA transaction: "if ( tx.isActive() ) { tx.setRollbackOnly(); }" The same check is necessary for CMT JTA using transactionManager.getStatus and looking if it is different than Status.NoTransaction. This check should be done above the code that call transactionManager.setRollbackOnly(); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
10
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-883) Index out of bound exception on range facets when IncludeZeroCount = false, maxCount > actual count

by Elmer van Chastelet (JIRA)

Index out of bound exception on range facets when IncludeZeroCount = false, maxCount > actual count --------------------------------------------------------------------------------------------------- Key: HSEARCH-883 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-883 Project: Hibernate Search Issue Type: Bug Components: query Affects Versions: 4.0.0.Alpha1, 3.4.1.Final Reporter: Elmer van Chastelet Attachments: FacetCollector.diff, RangeFacetingTest.diff As reported in the mailing list. I just upgraded to from HS 3.4.0 to 3.4.1. When using range faceting with includeZeroCount=false AND setMaxCount is set higher than the actual facets after filtering out the zero counts, I get this exception: {code} exception message: toIndex = 3 java.lang.IndexOutOfBoundsException: toIndex = 3 at java.util.ArrayList.subListRangeCheck(ArrayList.java:885) at java.util.ArrayList.subList(ArrayList.java:877) at org.hibernate.search.query.collector.FacetCollector.createSortedFacetList(FacetCollector.java:139) at org.hibernate.search.query.collector.FacetCollector.getFacetList(FacetCollector.java:128) at org.hibernate.search.query.engine.impl.QueryHits.updateTopDocs(QueryHits.java:236) at org.hibernate.search.query.engine.impl.QueryHits.<init>(QueryHits.java:127) at org.hibernate.search.query.engine.impl.HSQueryImpl.getQueryHits(HSQueryImpl.java:419) at org.hibernate.search.query.engine.impl.HSQueryImpl.queryDocumentExtractor(HSQueryImpl.java:275) at org.hibernate.search.query.engine.impl.FacetManagerImpl.getFacets(FacetManagerImpl.java:111) at org.webdsl.search.AbstractEntitySearcher.getFacets(AbstractEntitySearcher.java:520) {code} This is introduced by the fix for [HSEARCH-776|https://hibernate.onjira.com/browse/HSEARCH-776] Fix is easy and attached, just like an additional test. see: {code:java|title=FacetCollector.diff} Index: FacetCollector.java =================================================================== --- FacetCollector.java (revision 1712) +++ FacetCollector.java (working copy) @@ -136,7 +136,7 @@ facetList = createRangeFacetList( counter.getCounts().entrySet(), request, counter.getCounts().size() ); Collections.sort( facetList, new RangeDefinitionOrderFacetComparator( ) ); if ( facetRequest.getMaxNumberOfFacets() > 0 ) { - facetList = facetList.subList( 0, facetRequest.getMaxNumberOfFacets() ); + facetList = facetList.subList( 0, Math.min( facetRequest.getMaxNumberOfFacets(), facetList.size() ) ); } } else { {code} {code:java|title=Failing test} public void testRangeQueryRangeDefOrderMaxCountWithoutZeroCount() { FacetingRequest rangeRequest = queryBuilder( Fruit.class ).facet() .name( priceRange ) .onField( indexFieldName ) .range() .from( 0.00 ).to( 1.00 ) .from( 1.01 ).to( 1.50 ) .from( 1.51 ).to( 3.00 ) .from( 4.00 ).to( 5.00 ) .includeZeroCounts( false ) .orderedBy( FacetSortOrder.RANGE_DEFINITION_ODER ) .maxFacetCount(4) .createFacetingRequest(); FullTextQuery query = createMatchAllQuery( Fruit.class ); FacetManager facetManager = query.getFacetManager(); facetManager.enableFaceting( rangeRequest ); List<Facet> facets = query.getFacetManager().getFacets( priceRange ); assertFacetCounts( facets, new int[] { 2, 3, 5 } ); assertEquals( "[0.0, 1.0]", facets.get( 0 ).getValue() ); assertEquals( "[1.01, 1.5]", facets.get( 1 ).getValue() ); assertEquals( "[1.51, 3.0]", facets.get( 2 ).getValue() ); } {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-670) Add indexNullAs to @IndexedEmbedded

by Hardy Ferentschik (JIRA)

Add indexNullAs to @IndexedEmbedded ----------------------------------- Key: HSEARCH-670 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-670 Project: Hibernate Search Issue Type: New Feature Components: engine Affects Versions: 3.3.0.Final Reporter: Hardy Ferentschik Fix For: 3.4.0 See also https://forum.hibernate.org/viewtopic.php?f=9&t=1009125 Would look something like this: {code} @IndexedEmbedded(indexNullAs = Field.DEFAULT_NULL_TOKEN) {code} Need to be thought through on how this exactly works. -- 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, 7 months

3
4
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 August 2011