September 2011 - hibernate-issues

[Hibernate-JIRA] Created: (HSEARCH-899) Check for illegal usage of @IndexedEmbedded

by Sanne Grinovero (JIRA)

Check for illegal usage of @IndexedEmbedded ------------------------------------------- Key: HSEARCH-899 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-899 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Priority: Minor Fix For: 4.1 Apparently some people tend to assume that in indexed embedded classes all normal fields should use the @IndexedEmbedded annotation instead of @Field/.. like in: {code} @IndexedEmbedded String countryName {code} Might be nice to check for such unexpected usage, as it's currently silently ignored. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-655) Implements the FuturTask.cancel function in the massindexer

by Grégory Oliver (JIRA)

Implements the FuturTask.cancel function in the massindexer ----------------------------------------------------------- Key: HSEARCH-655 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-655 Project: Hibernate Search Issue Type: Improvement Components: massindexer Affects Versions: 3.3.0.Final Reporter: Grégory Oliver I can't use the massindexer because each time I stop the massindexer by killing the process, it corrupt the lucene directory. -- 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

13 years

3
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-863) Use JBoss Logging to create i18n exceptions

by Emmanuel Bernard (JIRA)

Use JBoss Logging to create i18n exceptions ------------------------------------------- Key: HSEARCH-863 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-863 Project: Hibernate Search Issue Type: Improvement Components: analyzer, directory provider, engine, infinispan, integration, mapping, massindexer, optimizer, query, serialization Reporter: Emmanuel Bernard This is not top priority but new code should follow this and encountered code should be migrated. If someone is willing to take the codebase over and convert the better {code} @MessageLogger(projectCode = "HSEARCH") public interface Log extends BasicLogger { @Message( value="Unable to start serialization layer", id=82 ) SearchException unableToStartSerializationLayer(@Cause Throwable e); } {code} And in the code throwing the exception {code} throw log.unableToStartSerializationLayer( e ); {code} ... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

2
9
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-812) Faceting: Possibiltiy to set behaviour (SHOULD/MUST) when selecting multiple facets should

by Elmer van Chastelet (JIRA)

Faceting: Possibiltiy to set behaviour (SHOULD/MUST) when selecting multiple facets should ------------------------------------------------------------------------------------------ Key: HSEARCH-812 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-812 Project: Hibernate Search Issue Type: Improvement Components: query Affects Versions: 3.4.0.Final Environment: - Reporter: Elmer van Chastelet Current implementation combines multiple facets from the same group by OR-ing them (SHOULD): {code} private Query createSelectionGroupQuery(FacetSelectionImpl selection) { BooleanQuery orQuery = new BooleanQuery(); for ( Facet facet : selection.getFacetList() ) { orQuery.add( facet.getFacetQuery(), BooleanClause.Occur.SHOULD ); } return orQuery; } {code} It might be useful to also allow AND-ing the facets. Some examples: When searching for publications, I want the publications where both 'Kim' and 'John' are author When searching for recipes, I want meals with both 'tomatoes' and 'eggs'. This is in case of fields that might have mutliple values, so its working is relying on [HSEARCH-726|https://hibernate.onjira.com/browse/HSEARCH-726]. I currently have adapted the code myself, to be able to set AND/OR as default facet combinator, but this is not using the Hibernate Search Query language contexts. This improvement should be easy to implement. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

4
10
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-521) Improve performance MassIndexer through Eager fetching

by Marc Schipperheyn (JIRA)

Improve performance MassIndexer through Eager fetching ------------------------------------------------------ Key: HSEARCH-521 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-521 Project: Hibernate Search Issue Type: Improvement Components: engine Affects Versions: 3.2.0.CR1 Reporter: Marc Schipperheyn Priority: Minor The MassIndexer fetches all of a certain entity from the database. It then proceeds to index it and the tree of IndexedEmbedded objects is traversed. In doing so, a lot of additional queries get executed. These queries are not really necessary, since we know beforehand that the data is needed for the indexing operation. So it would make sense to eagerly fetch all associations that are marked as indexEmbedded. This way MassIndexer would significantly speed up. -- 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

13 years

3
10
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-601) Allow MassIndexer to recover gracefully when individual objects won't index

by Ben Dotte (JIRA)

Allow MassIndexer to recover gracefully when individual objects won't index --------------------------------------------------------------------------- Key: HSEARCH-601 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-601 Project: Hibernate Search Issue Type: Improvement Components: massindexer Affects Versions: 3.2.0.Final Environment: Hibernate 3.5.3, SQL Server 2005 Reporter: Ben Dotte Some of our sites take hours to index, so it is critical that initial indexing complete even if some of the individual entities fail to index properly. Right now, it appears that the MassIndexer dies if any individual entity throws an exception during indexing, and does not complete indexing for that type. I have a workaround for now by overriding EntityConsumerLuceneworkProducer with my own index() method that catches and logs exceptions from docBuilder.createAddWork(): private void index( Object entity, Session session ) throws InterruptedException { Serializable id = session.getIdentifier( entity ); Class clazz = Hibernate.getClass( entity ); DocumentBuilderIndexedEntity docBuilder = documentBuilders.get( clazz ); TwoWayFieldBridge idBridge = docBuilder.getIdBridge(); String idInString = idBridge.objectToString( id ); //depending on the complexity of the object graph going to be indexed it's possible //that we hit the database several times during work construction. try { AddLuceneWork addWork = docBuilder.createAddWork( clazz, entity, id, idInString, true ); backend.enqueueAsyncWork( addWork ); } catch (Exception e) { log.error("Error indexing " + clazz + " id " + id, e); } } This has the added benefit that the object type and id that errored is logged, where that can be tough to track down otherwise. That may not be the best solution in general since it could hide exceptions from Hibernate Search itself. -- 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

13 years

3
16
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-797) Split programmatic mapping API classes to impl (

by Emmanuel Bernard (JIRA)

Split programmatic mapping API classes to impl ( ------------------------------------------------ Key: HSEARCH-797 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-797 Project: Hibernate Search Issue Type: Improvement Reporter: Emmanuel Bernard Fix For: 4.0 o Programmatic API *Mapping objects are messed up with *Descriptor objects It seems to be that *Descriptors should be private while *Mapping should be API, do you think it's worth working on this? The programmatic mapping si still considered experimental so we have some time I guess. => +1 let's do that, as you say not very urgent. -- 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

13 years

1
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-937) Search fails when loading associcated entity with different ID type

by Cody Lerum (JIRA)

Search fails when loading associcated entity with different ID type ------------------------------------------------------------------- Key: HSEARCH-937 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-937 Project: Hibernate Search Issue Type: Bug Affects Versions: 4.0.0.Beta2, 3.4.1.Final Reporter: Cody Lerum I have run into an issue after moving from Search 3.1 to 3.4.1 and later to 4.0.Beta2. The issue is that when loading an result entity from a hibernate search query the load fails if the result entity has an associated entity where the id types are dissimilar. For example if I have Company with an id type of Long and employee with id type of Integer and I search and the result is the company entity my search throws the following stack trace. aused by: java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Integer at org.hibernate.type.descriptor.java.IntegerTypeDescriptor.unwrap(IntegerTypeDescriptor.java:36) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.type.descriptor.sql.IntegerTypeDescriptor$1.doBind(IntegerTypeDescriptor.java:57) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.type.descriptor.sql.BasicBinder.bind(BasicBinder.java:82) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:305) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:300) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.loader.Loader.bindPositionalParameters(Loader.java:1909) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.loader.Loader.bindParameterValues(Loader.java:1880) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1758) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.loader.Loader.doQuery(Loader.java:828) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:289) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.loader.Loader.doList(Loader.java:2449) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.loader.Loader.doList(Loader.java:2435) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2276) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.loader.Loader.list(Loader.java:2271) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:121) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1484) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.internal.CriteriaImpl.list(CriteriaImpl.java:373) [hibernate-core-4.0.0.CR2.jar:4.0.0.CR2] at org.hibernate.search.query.hibernate.impl.CriteriaObjectsInitializer.initializeObjects(CriteriaObjectsInitializer.java:107) [hibernate-search-orm-4.0.0.Beta2.jar:] at org.hibernate.search.query.hibernate.impl.QueryLoader.executeLoad(QueryLoader.java:91) [hibernate-search-orm-4.0.0.Beta2.jar:] at org.hibernate.search.query.hibernate.impl.AbstractLoader.load(AbstractLoader.java:72) [hibernate-search-orm-4.0.0.Beta2.jar:] at org.hibernate.search.query.hibernate.impl.FullTextQueryImpl.list(FullTextQueryImpl.java:211) [hibernate-search-orm-4.0.0.Beta2.jar:] at org.hibernate.search.jpa.impl.FullTextQueryImpl.getResultList(FullTextQueryImpl.java:147) [hibernate-search-orm-4.0.0.Beta2.jar:] at com.domain.search.SearchUtil.search(SearchUtil.java:55) [classes:] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

4
10
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-663) Support wildcard and jolly characters in Query DSL

by Sanne Grinovero (JIRA)

Support wildcard and jolly characters in Query DSL -------------------------------------------------- Key: HSEARCH-663 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-663 Project: Hibernate Search Issue Type: Improvement Components: query Reporter: Sanne Grinovero Fix For: 3.4.0 -- 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

13 years

2
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-713) Drill-down faceting query should not affect other facet counts

by Sanne Grinovero (JIRA)

Drill-down faceting query should not affect other facet counts -------------------------------------------------------------- Key: HSEARCH-713 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-713 Project: Hibernate Search Issue Type: Improvement Components: query Reporter: Sanne Grinovero Assignee: Hardy Ferentschik Fix For: 3.4.0 Using the "drill-down" function in faceting should - at least by default - behave like Amazon's faceting: it affects the filtering of the list shown as current results but should not affect the faceting count of other facets. (It will of course affect sub-facets, so people can navigate up/down the facet tree to narrow down the results and explore different branches, but the parent branch and it's peers shouldn't be affected. It's still possible to apply global filters which affect all facets (like a filter applied on root): example enable "only items with at least 4 star reviews" might affect all counters in the tree. But if I'm in the area "TVs", and then the options {"LED", "Plasma"} open up, when we select "LED" the counters for both "Plasma" and "LED" should not change -> just of course the main results list will show only LED televisions. For those people who think it should be possible to affect such a drill down feature as a filter, they can still apply the filter globally (on the root query). {quote}<emmanuel> but to move forward, let's start with what we have. It seems that such alternative are definitely going to be an option on the FacetedManager <emmanuel> facetedManager.countAs(AMAZON) :){quote} -- 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

13 years

3
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues September 2011