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