August 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-305) Hibernate search doesn't work with criteria when it is not initialized laziily

by prabhu lal (JIRA)

Hibernate search doesn't work with criteria when it is not initialized laziily ------------------------------------------------------------------------------ Key: HSEARCH-305 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-305 Project: Hibernate Search Issue Type: Bug Components: query Affects Versions: 3.0.1.GA Environment: MYSQL,HIBERNATE 3.0 , Flex with dpHibernate Reporter: prabhu lal Attachments: QueryLoader.java For the RIA applications complete object tree should be initialized(To achieve that there is work around available like dpHibernate). But hibernate search doesn't apply criteria to queried result because it returns the result on the basis of wether objectt is intialized by loading the criteria objects.Since there is no lazy intiaialization so all the objects are loaded andcomplete result will be return irrespctive of criteria. code snipet from Hibernate Search API(org.hibernate.search.engine.QueryLoader.java.): public List load(EntityInfo... entityInfos) { final int maxResults = entityInfos.length; if ( maxResults == 0 ) return EMPTY_LIST; if ( entityType == null ) throw new AssertionFailure( "EntityType not defined" ); if ( criteria == null ) criteria = session.createCriteria( entityType ); DocumentBuilder builder = searchFactoryImplementor.getDocumentBuilders().get( entityType ); String idName = builder.getIdentifierName(); int loop = maxResults / MAX_IN_CLAUSE; boolean exact = maxResults % MAX_IN_CLAUSE == 0; if ( !exact ) loop++; Disjunction disjunction = Restrictions.disjunction(); for (int index = 0; index < loop; index++) { int max = index * MAX_IN_CLAUSE + MAX_IN_CLAUSE <= maxResults ? index * MAX_IN_CLAUSE + MAX_IN_CLAUSE : maxResults; List ids = new ArrayList( max - index * MAX_IN_CLAUSE ); for (int entityInfoIndex = index * MAX_IN_CLAUSE; entityInfoIndex < max; entityInfoIndex++) { ids.add( entityInfos[entityInfoIndex].id ); } disjunction.add( Restrictions.in( idName, ids ) ); } criteria.add( disjunction ); criteria.list(); //load all objects //mandatory to keep the same ordering List result = new ArrayList( entityInfos.length ); for (EntityInfo entityInfo : entityInfos) { Object element = session.load( entityInfo.clazz, entityInfo.id ); if ( Hibernate.isInitialized( element ) ) { //This is true for all the objects,in case objects are eagrly intialized //all existing elements should have been loaded by the query, //the other ones are missing ones result.add( element ); } } return result; } -- 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, 9 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-337) Search return the same row multiple times on Select

by Santhosh Kumaran (JIRA)

Search return the same row multiple times on Select --------------------------------------------------- Key: HSEARCH-337 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-337 Project: Hibernate Search Issue Type: Bug Environment: Hibernate Reporter: Santhosh Kumaran I have a table in the following pattern on MySQL 5.1 Table1 Key1 int Key2 int field1 tinyint field2 tinyint field3 tinyint I have the sql query like "SELECT {table1Entity.*} FROM TABLE1 table1 where Key1=?" This query will satify for 3 rows and has to get me the 3 filtered rows. and the code like this SQLQuery sqlQuery = session.createSQLQuery(query); sqlQuery.setInteger(0, 5001); sqlQuery = sqlQuery.addEntity("table1Entity", Table1Entity.class); List entityList = sqlQuery.list(); The list contain 3 entity objects, but 3 copies of the first row. ( not all 3 rows). First row coming 3 times instead of 2nd and 3rd row values. Please let me know, is it a bug or not? - SANSSAN -- 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, 9 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-341) Support for fetch joins in Hibernate search queries

by Seema Richard (JIRA)

Support for fetch joins in Hibernate search queries --------------------------------------------------- Key: HSEARCH-341 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-341 Project: Hibernate Search Issue Type: New Feature Components: query Affects Versions: 3.1.0.GA Reporter: Seema Richard In Hibernate search, the related entities marked using @IndexedEmbedded are now getting lazy fetched which is causing unnecessary queries to be generated. It would be useful if fetch joins can be used for better performance. -- 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, 9 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-350) @IndexedEmbedded appears to handle only declared type, not subtypes

by Taylor Mathewson (JIRA)

@IndexedEmbedded appears to handle only declared type, not subtypes ------------------------------------------------------------------- Key: HSEARCH-350 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-350 Project: Hibernate Search Issue Type: Improvement Components: mapping Reporter: Taylor Mathewson Given the following: @Indexed class A{ @IndexedEmbedded public B b; } class B{ ...//some indexed fields } public class C{ ...//some more indexed fields } The index for A will only contain the indexed fields in B, never the fields in C, even if the runtime type of A's b property is of class C. Thank you. -- 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, 9 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-313) Provide a callback on indexing exception

by Emmanuel Bernard (JIRA)

Provide a callback on indexing exception ---------------------------------------- Key: HSEARCH-313 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-313 Project: Hibernate Search Issue Type: New Feature Components: engine Reporter: Emmanuel Bernard An application can pass a callback and be notified when an indexing operation fails. The data associated with the operation is passed as a parameter (eg list of lucene work). The application can do anything from here: - log failing ids - swallow - put that in a queue for retry etc -- 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, 9 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-362) When using hibernate-search3.1.0 GA, Search throws AlreadyClosedException under certain circumstances

by S Ravi Bhaskar (JIRA)

When using hibernate-search3.1.0 GA, Search throws AlreadyClosedException under certain circumstances ----------------------------------------------------------------------------------------------------- Key: HSEARCH-362 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-362 Project: Hibernate Search Issue Type: Bug Components: directory provider Affects Versions: 3.1.0.GA Environment: Hibernate 3.2.6 GA, ant 1.7.1 Reporter: S Ravi Bhaskar The below code throws an AlreadyClosedException when trying to open the lucene index. Junit test to test it works from eclipse, fails in an ant build. I suspect it is trying to reuse a handle to the index. Please let me know if you need more information. I had to bump back my hibernate search version to 3.0.1 GA, and then it started working. I am getting by, but would ideally like to use 3.1.0 GA without this exception. I think it has something to do with Search.getFullTextEntityManager((getJpaPersistenceContext().getEntityManager())); VS Search.createFullTextEntityManager((getJpaPersistenceContext().getEntityManager())); in the older version. String query = "BlahBlahBlah"; org.apache.lucene.queryParser.QueryParser parser = new QueryParser("ItemTitle", new StandardAnalyzer() ); org.apache.lucene.search.Query luceneQuery; try { luceneQuery = parser.parse(query); } catch (ParseException e) { // TODO Auto-generated catch block logger.error(String.format("Error parsing search querystring ")); return null; } javax.persistence.Query fullTextQuery = createFullTextEntityManager().createFullTextQuery(luceneQuery, klass); List result = fullTextQuery.getResultList(); // return a list of managed where createFullTextEntityManager() is public FullTextEntityManager createFullTextEntityManager() { return Search.getFullTextEntityManager((getJpaPersistenceContext().getEntityManager())); } -- 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, 9 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-351) Index fields on subclasses of a field marked @IndexEmbedded

by Dimas Guardado, Jr. (JIRA)

Index fields on subclasses of a field marked @IndexEmbedded ----------------------------------------------------------- Key: HSEARCH-351 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-351 Project: Hibernate Search Issue Type: Improvement Affects Versions: 3.1.0.GA Reporter: Dimas Guardado, Jr. the fields of the subclasses of a property marked with @IndexedEmbedded are not getting indexed, but the fields of the base class are. I discussed this issue previously on the forums, and I was directed to file a JIRA issue for it. For more context and a code example to illustrate the problem, please see the following forum thread: http://forum.hibernate.org/viewtopic.php?p=2404209#2404209 -- 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, 9 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-387) Disable the automatic indexing as per session basis

by Behrang Javaherian (JIRA)

Disable the automatic indexing as per session basis --------------------------------------------------- Key: HSEARCH-387 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-387 Project: Hibernate Search Issue Type: New Feature Components: engine Affects Versions: 3.1.1.GA Reporter: Behrang Javaherian We are using the hibernate search and automatic indexing to index our model objects. The issue that we got is that anytime we touch a domain model and save the object, hibernate search is updating the underlying indexes and since our model objects are big it is time consuming. The are many cases that we know that the index doesn't need to be updated ( Like someone is just attaching an image to an article, etc). Is it possible to provide some sort of functionality to disable the automatic re-indexing per session. Thanks Behrang Javaherian http://www.beyondng.com -- 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, 9 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-396) disableFullTextFilter(String name) in FullTextQueryImpl does not disable the filter.

by wolfjourn (JIRA)

disableFullTextFilter(String name) in FullTextQueryImpl does not disable the filter. ------------------------------------------------------------------------------------ Key: HSEARCH-396 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-396 Project: Hibernate Search Issue Type: Bug Components: query Affects Versions: 3.1.1.GA Environment: Hibernate 3.3.2.GA Hibernate Annotations 3.4.0.GA RDBMS: MySQL, version: 5.0.70-log JDBC driver: MySQL-AB JDBC Driver, version: mysql-connector-java-5.1.6 Reporter: wolfjourn The disableFullTextFilter(String name) method in FullTextQueryImpl does not cause the filter to be disabled. This is due to incorrect logic in the buildFilters() method in the same class. For example, fullTextQuery = s.createFullTextQuery( query, Driver.class ); fullTextQuery.list().size(); /* Returns 10 */ fullTextQuery.enableFullTextFilter("security"); fullTextQuery.list().size(); /* Returns 5 */ fullTextQuery.disableFullTextFilter("security"); fullTextQuery.list().size(); /* Returns 5. Should return 10. */ Initially, buildFilters() constructs `filter' using the "security" filter from filterDefinitions. During the disableFullTextFilter("security") call, the filter is removed from `filterDefinitions'. However, `filter' remains intact. The subsequent call to buildFilters() returns immediately as `filterDefinitions' is now empty, leaving `filter' intact and thus not disabling the "security" filter. Furthermore, if a filter is disabled and replaced with another filter, the result will be a composition of both filters as towards the bottom of buildFilters(), any existing `filter' is chained onto the end of a new `chainedFilter'. This results in an empty result set if the sets returned by the filters are mutually exclusive. It looks like this issue was resolved with revision 16755. However, this is still worth documenting here for other 3.1.1.GA users that might run into the same issue. -- 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, 9 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-389) Filtering using criteria API is unreliable

by Dirk Mahler (JIRA)

Filtering using criteria API is unreliable ------------------------------------------ Key: HSEARCH-389 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-389 Project: Hibernate Search Issue Type: Bug Components: query Affects Versions: 3.1.1.GA, 3.1.0.GA Environment: Hibernate 3.3.2.GA, Hibernate Entity Manager 3.4.0.GA, Oracle 9.2 Reporter: Dirk Mahler Within one EntityManager session the following use case leads to wrong results if using Hibernate Search in combination with the Criteria API: 1. Execute a simple query which returns Entity A and B as results 2. Doing a full text query which will find A and B but restricts the results to A by doing a further filtering for an attribute which is only satisfied by A using the criteria API. Hibernate Search returns both A and B. After looking at the source code the reason seems to be the follwoing: - the full text search returns a list of entities - the Criteria query is simply used to initialize the entities within the EntityManager's session, the result set/list itself is ignored, see ObjectLoaderHelper#initializeObjects(EntityInfo[] entityInfos, Criteria criteria, Class<?> entityType, SearchFactoryImplementor searchFactoryImplementor): ... criteria.add( disjunction ); criteria.list(); //load all objects <-- ??? } - the result is now determined by checking wether the entities from the full text search are initialized using Hibernate.isInitalized(), see QueryLoader#load(EntityInfo... entityInfos and returnAlreadyLoadedObjectsInCorrectOrder(EntityInfo[] entityInfos, Session session)) This approach is highly fragile because it relies on side effects and should be discarded in favor of using the result of the criteria query which already represents the expected result. Is there any good reason to ignore it? -- 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, 9 months

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 August 2009