January 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-728) Backport MassIndexer to 3.1.X

by Chris Hornsey (JIRA)

Backport MassIndexer to 3.1.X ----------------------------- Key: HSEARCH-728 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-728 Project: Hibernate Search Issue Type: Task Components: massindexer Affects Versions: 3.1.1.GA Environment: Hibernate 3.3.X and any jboss server platform prior to 6.0. Reporter: Chris Hornsey Anyone using a non JPA2 version of hibernate is unable to utilize the capabilities of the MassIndexer introduced in version 3.2 of search. At a cursory glance I can not determine a dependency of the new indexer on JPA2. It would be very beneficial to make this available as utilizing hibernate search on existing application and manually indexing is obviously difficult with this new massindexer. Also anyone who chooses to use a supported version of jboss is excluded from this functionality until most likely 2012. If this is not possible i would appreciate an explanation of the dependencies the massindexer has on search 3.2. -- 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, 2 months

2
8
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-846) Backport HSEARCH-761 to 3.4 branch

by Kyrill Alyoshin (JIRA)

Backport HSEARCH-761 to 3.4 branch ---------------------------------- Key: HSEARCH-846 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-846 Project: Hibernate Search Issue Type: Improvement Components: engine Affects Versions: 3.4.0.Final Reporter: Kyrill Alyoshin HSEARCH-761 has turned out to be a critically important feature for us. See: https://forum.hibernate.org/viewtopic.php?f=9&t=1012198. It would be beyond awesome, if it could be back-ported to 3.4 branch. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-85) Asynchronous incremental optimizer

by Emmanuel Bernard (JIRA)

Asynchronous incremental optimizer ---------------------------------- Key: HSEARCH-85 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-85 Project: Hibernate Search Issue Type: New Feature Components: directory provider Reporter: Emmanuel Bernard Priority: Minor The indexing process itself can be asynchronous, but if not, it would be nice to make the optimization process optionally asynchronous -- 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, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-182) Use Directory getLockID() to uniquely identify a directory provider

by Emmanuel Bernard (JIRA)

Use Directory getLockID() to uniquely identify a directory provider ------------------------------------------------------------------- Key: HSEARCH-182 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-182 Project: Hibernate Search Issue Type: Improvement Components: directory provider Reporter: Emmanuel Bernard Priority: Minor Fix For: 3.1.0 Today the DirectoryProvider needs to implement equals and hashCode so that the underlying Directory is unique. We could delegate that to the directory.getLockID() which seem to fulfill the same contract. Not sure it works well with our lazy initialization strategy though. This needs to be checked out. -- 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, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-972) Make it possible to plug in custom OptimizerStrategy implementations

by Sanne Grinovero (JIRA)

Make it possible to plug in custom OptimizerStrategy implementations -------------------------------------------------------------------- Key: HSEARCH-972 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-972 Project: Hibernate Search Issue Type: New Feature Reporter: Sanne Grinovero -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-682) DSL cannot handle fieldBridge for @IndexEmbedded fields

by Nick Fenwick (JIRA)

DSL cannot handle fieldBridge for @IndexEmbedded fields ------------------------------------------------------- Key: HSEARCH-682 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-682 Project: Hibernate Search Issue Type: New Feature Components: engine Affects Versions: 3.3.0.Final Environment: Hibernate 3.6.0, HSearch 3.3.0, Mysql 5.1.52. Reporter: Nick Fenwick Discussed in https://forum.hibernate.org/viewtopic.php?f=9&t=1009440, "Re: Correct to use ignoreFieldBridge for "subentity.field" DSL?". I find I have to set ignoreFieldBridge when querying for a field indexed using @IndexEmbedded, i.e.: {code}@Entity class CategoryEntity { @Column(name="lft") @Field(name="left", index=Index.UN_TOKENIZED, store=Store.YES) @FieldBridge(impl=PadNumberBridge.class, params = { @Parameter(name="pad", value="4") } ) private int left; ... same for 'right' ... } @Entity class ItemEntity { @IndexedEmbedded(depth=1) private CategoryEntity category; }{code} results in fields for ItemEntity being stored in the Lucene index like: {code} category.left = 0004 category.right = 0012 {code} To query for these, I cannot do: {code} qb.range().onField("category.left").above(4).createQuery() {code} I get an exception saying it doesn't know what FieldBridge to use for "category.left". Instead, I can do: {code} qb.range().onField("category.left").ignoreFieldBridge().above(4).createQuery() {code} but the 'value' is no longer padded according to the FieldBridge that was specified in CategoryEntity for its 'left' attribute, I have to pass value as e.g. "0004". It would be good to mention this situation in the documentation (5.1.2. "Building a Lucene query with the Hibernate Search query DSL"), at least to specify that it is/isn't supported, so that people attempting this kind of @IndexEmbedded mapping know how to safely build a query for such fields. -- 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, 2 months

4
11
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-551) Using Programamtic API, getters are not inherited

by Chaffotte (JIRA)

Using Programamtic API, getters are not inherited ------------------------------------------------- Key: HSEARCH-551 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-551 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.2.0.Final Environment: hibernate 3.5.1-Final, hsqldb 1.8.0.7 Reporter: Chaffotte Attachments: search2.zip Using Programamtic API, if getters are not defined (overrided) in the child class, the search does not find anything! I had a simple example, remove comments in MySubClass in order to get all tests green! -- 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, 2 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-827) Remove the Worker executor

by Sanne Grinovero (JIRA)

Remove the Worker executor -------------------------- Key: HSEARCH-827 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-827 Project: Hibernate Search Issue Type: Remove Feature Components: engine Reporter: Sanne Grinovero Fix For: 4.0 There's no need any more to keep this executor around, it's only adding up some complexity, and possibly messing with order of LuceneWorks being applied, when used in a non-default threadpool size (which is one, providing a bottleneck too). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1032) MassIndexer with a update mechanism

by Marcel (JIRA)

MassIndexer with a update mechanism ----------------------------------- Key: HSEARCH-1032 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-1032 Project: Hibernate Search Issue Type: New Feature Components: massindexer Affects Versions: 4.0.0.Final Reporter: Marcel A feature which is already discussed in https://forum.hibernate.org/viewtopic.php?f=9&t=1014063: It would be great to see an update mechanism instead of an index wipe/rebuild. I got a lot of data (> 17 mio rows) which takes a long time (> 2 hours) to index, which is needed because I don't only manipulate the data with hibernate. While the massindexer is rebuilding the index, the search will miss some of the rows which are not indexed yet, which is not acceptable for me. Instead of wiping the index and re-adding all rows, update only the changed ones (new, updated, deleted). The current process is: 1) wipe out the index 2) Add again all entities from the database, loading and processing them with multiple threads but 2) could be replaced by an update instead of an add operation. But then as a new 3) step, it should look for entries/rows which are deleted from the database and remove them from the index too. the 3) phase is not top priority for me but would possibly lead other people to use this approach instead of the wipe/reindex procedure (for large datasets). Maybe it can be split, to have an operation only to update the index (without delete) and a second operation to delete already deleted data (on database) from the index. The whole operation doesn't need to be as fast as the wipe/reindex operation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HV-425) AbstractMethodError in WebLogic 10.3.4

by Torsti Töllinen (JIRA)

AbstractMethodError in WebLogic 10.3.4 -------------------------------------- Key: HV-425 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-425 Project: Hibernate Validator Issue Type: Bug Components: engine Affects Versions: 4.2.0.Beta1 Environment: WebLogic 10.3.4 Hibernate Validator 4.2.0.Beta1 Spring Framework 3.0.5 Reporter: Torsti Töllinen Validation fails on WebLogic 10.3.4 with HV 4.2.0.Beta1. WebLogic has been patched with patch QWG8 (Enable JPA 2.0 support on WebLogic Server. CR/BUG 9923849). With WebLogic version 10.3.3, HV works. java.lang.AbstractMethodError: org.apache.openjpa.persistence.PersistenceProviderImpl.getProviderUtil()Ljavax/persistence/spi/ProviderUtil; at javax.persistence.Persistence$PersistenceUtilImpl.isLoaded(Unknown Source) at org.hibernate.validator.engine.resolver.JPATraversableResolver.isReachable(JPATraversableResolver.java:61) at org.hibernate.validator.engine.resolver.DefaultTraversableResolver.isReachable(DefaultTraversableResolver.java:131) at org.hibernate.validator.engine.resolver.SingleThreadCachedTraversableResolver.isReachable(SingleThreadCachedTraversableResolver.java:46) at org.hibernate.validator.engine.ValidatorImpl.isValidationRequired(ValidatorImpl.java:1126) at org.hibernate.validator.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:405) at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForRedefinedDefaultGroup(ValidatorImpl.java:341) at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:325) at org.hibernate.validator.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:281) at org.hibernate.validator.engine.ValidatorImpl.validate(ValidatorImpl.java:129) at org.springframework.validation.beanvalidation.SpringValidatorAdapter.validate(SpringValidatorAdapter.java:86) at org.springframework.validation.DataBinder.validate(DataBinder.java:692) at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.doBind(HandlerMethodInvoker.java:807) at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.resolveHandlerArguments(HandlerMethodInvoker.java:359) at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:171) at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:426) at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:414) at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:790) at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644) at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:560) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:183) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3717) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207) at weblogic.work.ExecuteThread.run(ExecuteThread.java:176) -- 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, 2 months

5
11
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 January 2012