November 2011 - hibernate-issues - Jboss List Archives

[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

14 years, 3 months

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

14 years, 3 months

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

14 years, 3 months

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

14 years, 3 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-634) Improve Query DSL to support multi terms search

by Emmanuel Bernard (JIRA)

Improve Query DSL to support multi terms search ----------------------------------------------- Key: HSEARCH-634 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-634 Project: Hibernate Search Issue Type: Improvement Components: query Affects Versions: 3.3.0.CR1 Reporter: Emmanuel Bernard Fix For: 3.4.0 {code}final Query luceneQuery = builder .bool() .should( builder .keyword() .onField( "title" ).boostedTo( 4f ) .andField( "description" ) .matching( "plants" ) .createQuery() ) .should( builder .keyword() .onField( "title" ).boostedTo( 4f ) .andField( "description" ) .matching( "hands" ) .createQuery() ) .createQuery();{code} is too verbose can could be done as {code}final Query luceneQuery = builder .keyword() .onField( "title" ).boostedTo( 4f ) .andField( "description" ) .matching( "plants", "hands" ) .createQuery();{code} -- 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, 3 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-633) Allow definition of annotations at package-level in package-info.java

by Michael Mogley (JIRA)

Allow definition of annotations at package-level in package-info.java --------------------------------------------------------------------- Key: HSEARCH-633 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-633 Project: Hibernate Search Issue Type: Improvement Affects Versions: 3.3.0.CR1 Environment: Hibernate 3.6, Oracle 10g Reporter: Michael Mogley Priority: Minor Currently, it is not possible to define package-level annotations, for example a set of analyzer definitions that are shared by all classes in a package. Having this feature would really aid in code organization, allowing global search-related annotations to be separate from model classes. The situation right now, where an AnalyzerDef annotation defined in one model class is also referencable from another model class, is not intuitive. Please see the thread below: https://forum.hibernate.org/viewtopic.php?f=9&t=1008145&p=2438323#p2438323 -- 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, 3 months

4
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-795) Move some of SearchFactoryImplementor from spi to impl (and move used contracts up)

by Emmanuel Bernard (JIRA)

Move some of SearchFactoryImplementor from spi to impl (and move used contracts up) ----------------------------------------------------------------------------------- Key: HSEARCH-795 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-795 Project: Hibernate Search Issue Type: Improvement Reporter: Emmanuel Bernard Fix For: 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

14 years, 3 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-349) Allow custom Loader in FullTextQueryImpl

by Julien Kronegg (JIRA)

Allow custom Loader in FullTextQueryImpl ---------------------------------------- Key: HSEARCH-349 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-349 Project: Hibernate Search Issue Type: New Feature Components: query Affects Versions: 3.1.0.GA Environment: Hibernate 3.3.1.GA, DB2 Reporter: Julien Kronegg Priority: Minor When doing an native SQL query containing join and other complicated stuff, one can get a List<MyObject> using the following code: List<MyObject> list = entityManager.createNativeQuery("SELECT ...", MyObject.class).getResultList(); The MyObject class is an JPA Entity, but is not connected to a database table: the MyObject instance is reconstructed automatically by mapping the ResultSet column names and the MyObject field names. This object list can be indexed using Hibernate Search (by adding @Indexed and @Field annotations to the MyObject entity). When doing an Hibernate Search query, the FullTextQueryImpl.list() method uses a Loader which try to load the MyObject entities from the database by a query such as "SELECT ... FROM MYOBJECT where id in (?,?,?,..)" (where the list of "?" is the list of identifiers returned by Lucene). Here, we have a problem: the MYOBJECT table does not exist and obviously an exception is raised. The desired result would be for example to look into the initial List<MyObject> "list" instead of asking to the database. This functionnality could be done very simply by adding a "Loader customLoader" field (with its public getter/setter) in the org.hibernate.search.query.FullTextQueryImpl class and by modifying the getLoader() method such as: private Loader getLoader(Session session, SessionFactoryImplementor sessionFactoryImplementor) { if (customLoader!=null) { customLoader.init(session, sessionFactoryImplementor); return customLoader; } ... } After this modification, the programmer can design its own Loader which implements whatever loading strategy. For the example above, the Loader.load(EntityInfo[]) method may looks for each EntityInfo.id in the initially obtained List<MyObject> "list". There is a workaround: copy the full source code of FullTextQueryImpl and add the described modifications. -- 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, 3 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-668) Provide a setting to bring under the same transaction the DB operation and the Infinispan Lucene Directory

by Emmanuel Bernard (JIRA)

Provide a setting to bring under the same transaction the DB operation and the Infinispan Lucene Directory ---------------------------------------------------------------------------------------------------------- Key: HSEARCH-668 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-668 Project: Hibernate Search Issue Type: New Feature Reporter: Emmanuel Bernard Assignee: Sanne Grinovero As discussed on the call with Grant -- 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, 3 months

3
9
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-777) The ErrorContext passed into ErrorHandler should include a flag indicating whether it's running in batch mode

by Nikita D (JIRA)

The ErrorContext passed into ErrorHandler should include a flag indicating whether it's running in batch mode ------------------------------------------------------------------------------------------------------------- Key: HSEARCH-777 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-777 Project: Hibernate Search Issue Type: Improvement Components: integration Affects Versions: 3.4.0.Final Reporter: Nikita D Priority: Minor Hibernate Search allows defining a custom error handler for indexing errors (implements org.hibernate.search.exception.ErrorHandler). The ErrorHandler receives an ErrorContext with metadata about the error. It would be very useful to add the following method to the ErrorContext passed into the ErrorHandler: {code} boolean isBatchMode(); {code} This way a custom error handler can deal with errors that occur during a batch operation differently from regular operations. -- 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, 3 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 November 2011