December 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth

by Zach Kurey (JIRA)

Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth --------------------------------------------------------------------------------------------------------- Key: HSEARCH-886 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886 Project: Hibernate Search Issue Type: New Feature Components: engine, mapping Reporter: Zach Kurey Frequently its desirable to index a particular embedded type differently depending on the use case of the referencing type that is the primary subject being indexed. Additionally, depth in general causes many more paths to be included in a document than necessary for a particular index. This makes tuning of indexing to eliminate problem paths difficult, and sometimes impossible if a particular object model re-uses a lot of types. The proposal/improvement has already been discussed more in depth here: http://www.mail-archive.com/hibernate-dev@lists.jboss.org/msg06548.html, and what follows reflects some of that discussion. As an example of how specific paths could be configured for indexing: @Indexed class A{ @IndexEmbedded( depth=0, @IndexPaths(paths={"d.one", "d.two"}) ) private C see; } @Indexed class B{ @IndexEmbedded( depth=0, @IndexPaths(paths={"foo"}) ) private C see; } class C{ @IndexEmbedded private Collection<D> d; @Field private int foo; } class D{ @Field int one; @Field int two; } Index A would contain: d.one, and d.two Index B would contain: foo, but would NOT contain anything from path 'd'. Perhaps indexing path 'd' has a performance impact that is desirable to eliminate for B, but acceptable or necessary for A. This ability would also help to eliminate the bloat of unnecessary fields in lucene documents; which may not itself be a performance problem, but leaves a lot of things to rule out when tracking down indexing issues(both performance or content). Lastly. To be clear, the above proposal(which really Sanne came up with in the email thread) does not conflict with depth. Here are some further examples of how depth may interact with explicit paths: @IndexEmbedded(depth=3, paths={"a.b.c.d.e"}) Says to index all paths up to depth 3, but additionally index path 'a.b.c.d.e'. @IndexEmbedded(depth=0, paths={"a.b.c.d.e"}) Says to only index path 'a.b.c.d.e' @IndexEmbedded( paths={"a.b.c.d.e"}) Default behavior, depth is unlimited, specifying a.b.c.d.e is redundant in this case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

6
20
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-856) Implement HibernateSearchIntegrator#integrate(MetadataImplementor, SessionFactoryImplementor, SessionFactoryServiceRegistry)

by Hardy Ferentschik (JIRA)

Implement HibernateSearchIntegrator#integrate(MetadataImplementor, SessionFactoryImplementor, SessionFactoryServiceRegistry) ----------------------------------------------------------------------------------------------------------------------------- Key: HSEARCH-856 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-856 Project: Hibernate Search Issue Type: Task Reporter: Hardy Ferentschik Once _Configuration_ gets deprecated and the switch to _MetadataImplementor_ is complete is the right way to integrate w/ Core is via _Integrator.integrate(MetadataImplementor, SessionFactoryImplementor, SessionFactoryServiceRegistry)_ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

3
6
0 / 0

[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

12 years, 11 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

12 years, 11 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

12 years, 11 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

12 years, 11 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

12 years, 11 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

12 years, 11 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

12 years, 11 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

12 years, 11 months

2
7
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues December 2011