July 2011 - hibernate-issues - Jboss List Archives

[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, 4 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, 4 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, 4 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-810) @NumericFields with NumericField forName require @Field to use name=

by Izaak Alpert (JIRA)

@NumericFields with NumericField forName require @Field to use name= -------------------------------------------------------------------- Key: HSEARCH-810 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-810 Project: Hibernate Search Issue Type: Bug Reporter: Izaak Alpert Priority: Minor It seems that unless name for the first @Field is specified range searches on that field will not be numeric Doesn't work: public class TestExampleClass { @Fields({ @Field( index = Index.UN_TOKENIZED), @Field(name = "quantityFitted_forSort", index = Index.UN_TOKENIZED, store = Store.YES) }) @NumericFields({ @NumericField(forField = "quantityFitted") }) private Integer quantityFitted; } public class TestExampleClass { @Fields({ @Field(name = "quantityFitted", index = Index.UN_TOKENIZED), @Field(name = "quantityFitted_forSort", index = Index.UN_TOKENIZED, store = Store.YES) }) @NumericFields({ @NumericField(forField = "quantityFitted") }) private Integer quantityFitted; } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

4
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-697) Think about improving type mismatch detection between QueryBuilder output and targeted FullTextQuery

by Sanne Grinovero (JIRA)

Think about improving type mismatch detection between QueryBuilder output and targeted FullTextQuery ---------------------------------------------------------------------------------------------------- Key: HSEARCH-697 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-697 Project: Hibernate Search Issue Type: Bug Components: query Reporter: Sanne Grinovero Fix For: 3.4.0.Beta1 Use cases: 1)we ask for the target type when creating a QueryBuilder, then we ask again for the same information again at FullTextQuery creation - they must match. 2)it seems that when people get the match wrong, they receive cryptic error messages (see https://forum.hibernate.org/viewtopic.php?f=9&t=1009700 ) It would be nice if we could infer the target type from the builder, we'd likely have to introduce a new class hiding away org.apache.search.Query in something which knows a bit more about types. Or maybe introduce a new method in FullTextSession to create a Hibernate.Query directly from the builder, projecting on the known types. train of thoughts.. maybe this could lead to a typesafe API to define fulltext projections reusing JPA2 metamodel in case it's available. -- 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, 4 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-431) More details in documentation about MassIndexer

by Sanne Grinovero (JIRA)

More details in documentation about MassIndexer ----------------------------------------------- Key: HSEARCH-431 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-431 Project: Hibernate Search Issue Type: Task Components: documentation Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 3.2.0.Beta3 Add the new diagram Emmanuel has drawn with explanations about the different stages and pipelines of MassIndexer. -- 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, 4 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-818) Cacheable instance filters are created multiple times before being cached

by Sanne Grinovero (JIRA)

Cacheable instance filters are created multiple times before being cached ------------------------------------------------------------------------- Key: HSEARCH-818 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-818 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.4.0.Final Reporter: Sanne Grinovero Fix For: 4.0 Filters are being built during SessionFactory creation a first time, only to test creation capabilities, and then again in org.hibernate.search.query.engine.impl.HSQueryImpl.buildLuceneFilter(FullTextFilterImpl) The filter instance is created first with createFilterInstance, and only *after* being created we look it up in the cache. Same issue with Filter Factories, the factories are not cached. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-152) Consider using SnapshotDeletionPolicy for hot backup instead of the old locking scheme

by Emmanuel Bernard (JIRA)

Consider using SnapshotDeletionPolicy for hot backup instead of the old locking scheme -------------------------------------------------------------------------------------- Key: HSEARCH-152 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-152 Project: Hibernate Search Issue Type: New Feature Components: directory provider Reporter: Emmanuel Bernard Not sure it's really interesting in our environment though -- 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, 4 months

2
11
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-826) Optionally allow WorkQueuePerIndexSplitter to apply changes to indexes in parallel

by Sanne Grinovero (JIRA)

Optionally allow WorkQueuePerIndexSplitter to apply changes to indexes in parallel ---------------------------------------------------------------------------------- Key: HSEARCH-826 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-826 Project: Hibernate Search Issue Type: New Feature Components: engine Reporter: Sanne Grinovero Fix For: 4.0 I think there should be two different implementations of this, a simple one like the current implementation and an alternative strategy using an Executor and waiting for each operation to complete. Async indexes could be dealt with to optimize the no-wait, but the IndexManager would return immediately anyway. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-692) FieldSelection should be allowed in more cases

by Sanne Grinovero (JIRA)

FieldSelection should be allowed in more cases ---------------------------------------------- Key: HSEARCH-692 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-692 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Fix For: 3.5 The allowFieldSelection is now turned off by the DocumentBuilder if the entity contains any field which is not two-way projectable. This results in having FieldSelectors being disabled, even if the only field being asked for as projection contains only two-way projectable fields. Also, the current code in org.hibernate.search.engine.DocumentBuilderIndexedEntity.checkAllowFieldSelection() is a mess; we should figure out from the bridges exactly which fields they are going to need to read: FieldSelector needs now to be disabled for bridges such as org.hibernate.search.test.id.PersonPKBridge. -- 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, 4 months

1
2
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 July 2011