[Hibernate-JIRA] Created: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
3:23 p.m.
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
3:38 p.m.
New subject: [Hibernate-JIRA] Updated: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886?pag...
]
Sanne Grinovero updated HSEARCH-886:
------------------------------------
Suitable for new contributors: [Yes, likely]
Description:
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.
was:
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.
Fix Version/s: 4.0
I'm setting it very optimistically for version 4.0, and contributor patches and
proposals are very welcome. More likely for >4.1
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
Fix For: 4.0
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
3:51 a.m.
New subject: [Hibernate-JIRA] Assigned: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886?pag...
]
Davide D'Alto reassigned HSEARCH-886:
-------------------------------------
Assignee: Davide D'Alto
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
Assignee: Davide D'Alto
Fix For: 4.0
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
3:53 a.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886?pag...
]
Davide D'Alto commented on HSEARCH-886:
---------------------------------------
I hope it's not a problem if I assign this to me.
I've already created a prototype:
https://github.com/hibernate/hibernate-search/pull/156
Cheers,
Davide
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
Assignee: Davide D'Alto
Fix For: 4.0
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
9:56 p.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886?pag...
]
Zach Kurey commented on HSEARCH-886:
------------------------------------
Hey Davide.
Not a problem. I just freed up some time to work on this and was quite happy to get an
email yesterday letting me know it mostly done already. Thanks! = )
I gave your changes a try today and saw a 5x improvement in indexing speed on some
problematic entities. Also load on the system doing the indexing was much lower compared
to the CPU pinning that was happening from traversing cycles, and in general indexing more
than was needed.
The only thing that was missing was to add path support to 'checkForFields(..)',
as opposed to just 'checkForField(..)' in AbstractDocumentBuilder.
I did have an issue where I improperly indexed an entity for a non-existent path and it
would have silently failed. The code just checks if the current path being traversed is
part of the specified paths, but no upfront checking is done to ensure that the paths are
valid in the first place. It would probably eliminate a lot of configuration mistakes and
confusion to add some validation there.
I also saw your question about whether or not depth should be automatically set to 0 if it
isn't specified but paths are. It does seem incorrect to have unlimited depth and
paths together, so I'd lean towards yes.
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
Assignee: Davide D'Alto
Fix For: 4.0
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
8:45 a.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886?pag...
]
Davide D'Alto commented on HSEARCH-886:
---------------------------------------
Awesome!
Thanks for the feedback.
I think I will be able to create a new patch that fix those points in a couple of days
Cheers
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
Assignee: Davide D'Alto
Fix For: 4.0
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
7:07 a.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886?pag...
]
Davide D'Alto commented on HSEARCH-886:
---------------------------------------
I've rebased the project and I've added the suggested changes.
Without considering new bugs the only missing thing is the validation (I'm thinking
how to do that at the moment).
Thanks for the help,
Davide
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
Assignee: Davide D'Alto
Fix For: 4.0
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
9:36 a.m.
New subject: [Hibernate-JIRA] Updated: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886?pag...
]
Sanne Grinovero updated HSEARCH-886:
------------------------------------
Fix Version/s: (was: 4.0)
4.0.0.CR1
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
Assignee: Davide D'Alto
Fix For: 4.0.0.CR1
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
7:20 a.m.
New subject: [Hibernate-JIRA] Updated: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886?pag...
]
Emmanuel Bernard updated HSEARCH-886:
-------------------------------------
Fix Version/s: (was: 4.0.0.CR1)
4.0
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
Assignee: Davide D'Alto
Fix For: 4.0
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
7:39 a.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886?pag...
]
Davide D'Alto commented on HSEARCH-886:
---------------------------------------
{quote}
@IndexEmbedded( paths=\{"a.b.c.d.e"\})
Default behavior, depth is unlimited, specifying a.b.c.d.e is redundant in this case.
{quote}
The submitted patch (https://github.com/hibernate/hibernate-search/pull/156) behaves
differently in this case: depth is set to 0
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
Assignee: Davide D'Alto
Fix For: 4.0
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
4:14 a.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886?pag...
]
Hardy Ferentschik commented on HSEARCH-886:
-------------------------------------------
Another feature request for this -
https://forum.hibernate.org/viewtopic.php?f=9&t=1013320&p=2450125
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
Assignee: Davide D'Alto
Fix For: 4.0.0.Final
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
9:07 a.m.
New subject: [Hibernate-JIRA] Updated: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886?pag...
]
Sanne Grinovero updated HSEARCH-886:
------------------------------------
Fix Version/s: (was: 4.0.0.Final)
4.1
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
Assignee: Davide D'Alto
Fix For: 4.1
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
10:39 a.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886?pag...
]
Sanne Grinovero commented on HSEARCH-886:
-----------------------------------------
glad to say we can resume this work now that 4.0.0.Final is out :)
Thanks for your patience and don't get me wrong, I'm very interested in this.
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
Assignee: Davide D'Alto
Fix For: 4.1
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:46 p.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886?pag...
]
Zach Kurey commented on HSEARCH-886:
------------------------------------
It's easy to be patient since I've back ported this to a custom 3.4.1. = )
Has the @ContainedIn concern that was mentioned on github been addressed? Its not clear
to me what tied the two issues(HSEARCH-513 and this) together.
In any case. Thanks for the update and congrats on getting 4.0.0.Final out the door.
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
Assignee: Davide D'Alto
Fix For: 4.1
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
1:52 p.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886?pag...
]
Davide D'Alto commented on HSEARCH-886:
---------------------------------------
The @ContainedIn concern was the one addressed by HSEARCH-638
It shouldn't be connected to this one but I've created a patch prototype for it:
https://github.com/hibernate/hibernate-search/pull/217
I like the fact that you've just released something and you are thinking to the next
goals.
Great stuff!
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
Assignee: Davide D'Alto
Fix For: 4.1
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
8:40 a.m.
New subject: [Hibernate-JIRA] Updated: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-886?pag...
]
Emmanuel Bernard updated HSEARCH-886:
-------------------------------------
Fix Version/s: (was: 4.1)
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
Assignee: Davide D'Alto
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
11:58 a.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
https://hibernate.onjira.com/browse/HSEARCH-886?page=com.atlassian.jira.p...
]
Marc Schipperheyn commented on HSEARCH-886:
-------------------------------------------
Adding paths as a selectable extension to depth is a welcome addition. For me, most cases
seem to be more related to the ability to exclude certain paths based on a given depth.
I'm wondering if just having the option to add paths would not lead to low depth
setting at root entities with a great list of paths to be added.
Provide the ability to configure specific paths to index within
@IndexEmbedded as an alternative to depth
---------------------------------------------------------------------------------------------------------
Key: HSEARCH-886
URL: https://hibernate.onjira.com/browse/HSEARCH-886
Project: Hibernate Search
Issue Type: New Feature
Components: engine, mapping
Reporter: Zach Kurey
Assignee: Davide D'Alto
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:23 p.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
https://hibernate.onjira.com/browse/HSEARCH-886?page=com.atlassian.jira.p...
]
Sanne Grinovero commented on HSEARCH-886:
-----------------------------------------
Marc, do you really have many more deep paths than short ones? That would likely
significantly change the way we'll have to design the annotation.
I was hoping to avoid having a "removePath" or similar as that make it much more
complex to understand. Could you live with adding them?
Provide the ability to configure specific paths to index within
@IndexEmbedded as an alternative to depth
---------------------------------------------------------------------------------------------------------
Key: HSEARCH-886
URL: https://hibernate.onjira.com/browse/HSEARCH-886
Project: Hibernate Search
Issue Type: New Feature
Components: engine, mapping
Reporter: Zach Kurey
Assignee: Davide D'Alto
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
5:52 p.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
https://hibernate.onjira.com/browse/HSEARCH-886?page=com.atlassian.jira.p...
]
Zach Kurey commented on HSEARCH-886:
------------------------------------
I don't think it impacts the design that much if we were to go with something like my
latest suggestion of deprecate @IndexEmbedded, and add new annotations
@IndexEmbeddedByDepth and @IndexEmbeddedByPaths. @IndexEmbeddedByPaths does seem a bit
awkward at a glance this way(excludes is an attributes of the depth approach, and includes
has its own annotation), but really you are talking about two different approaches. The
first auto index using depth, and then weed out problem paths. The other explicitly index
only certain paths.
Just to summarize my latest suggestion on the github thread(which may be a wild idea, but
just trying to break the log jam). I'm proposing
- Deprecate @IndexEmbedded. This is for two reasons.
1. Its debatable(too subject to opinion) whether or not depth should be implicitly set
to 0 under the covers if depth is NOT specified but 'includePaths' IS specified,
or whether the default annotation value should be law and what is used at runtime, which
is intuitive to some and unintuitive to others.
2. The second is deprecation advertises to users of newer versions of hibernate search
that there are alternatives to consider when indexing.
- Add @IndexEmbeddedByDepth(depth=N). Personally I think depth should be required to be
specified. Users can still achieve infinite depth by setting the value to
Integer.MAX_VALUE. But really, at least in my use cases, I've always wanted to
carefully consider this value, and making it required shouldn't add that much time to
prototyping.
- Add @IndexEmbeddedByPaths(paths={}), which if used by itself provides a simple way to
index some explicit set of paths. If used in conjunction with @IndexEmbeddedByPaths, is
useful if you want a few paths that exceed the depth you specified(but you don't want
all paths to go past that depth).
I know the community needs a way to explicitly include paths as an option for getting rid
of unnecessary paths. I'd really like to get that finalized soon since this is really
dragging on. Then maybe we can wait and see if there is a large desire to add
excludePaths in the future and add it when that becomes more clear? The suggestion
I'm throwing out there would leave the door open to that(adding it as an attribute of
@IndexEmbeddedByDepth in the future).
Provide the ability to configure specific paths to index within
@IndexEmbedded as an alternative to depth
---------------------------------------------------------------------------------------------------------
Key: HSEARCH-886
URL: https://hibernate.onjira.com/browse/HSEARCH-886
Project: Hibernate Search
Issue Type: New Feature
Components: engine, mapping
Reporter: Zach Kurey
Assignee: Davide D'Alto
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
8:22 p.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
https://hibernate.onjira.com/browse/HSEARCH-886?page=com.atlassian.jira.p...
]
Marc Schipperheyn commented on HSEARCH-886:
-------------------------------------------
I could certainly live with adding them. I'd be happy with any way to do it. Just
wondering what would be the most obvious use case.
Provide the ability to configure specific paths to index within
@IndexEmbedded as an alternative to depth
---------------------------------------------------------------------------------------------------------
Key: HSEARCH-886
URL: https://hibernate.onjira.com/browse/HSEARCH-886
Project: Hibernate Search
Issue Type: New Feature
Components: engine, mapping
Reporter: Zach Kurey
Assignee: Davide D'Alto
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
3:07 a.m.
New subject: [Hibernate-JIRA] Updated: (HSEARCH-886) Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth
[
https://hibernate.onjira.com/browse/HSEARCH-886?page=com.atlassian.jira.p...
]
Sanne Grinovero updated HSEARCH-886:
------------------------------------
Fix Version/s: 4.1.0.Beta2
Provide the ability to configure specific paths to index within
@IndexEmbedded as an alternative to depth
---------------------------------------------------------------------------------------------------------
Key: HSEARCH-886
URL: https://hibernate.onjira.com/browse/HSEARCH-886
Project: Hibernate Search
Issue Type: New Feature
Components: engine, mapping
Reporter: Zach Kurey
Assignee: Davide D'Alto
Fix For: 4.1.0.Beta2
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
4603
days inactive
4770
days old
hibernate-issues@lists.jboss.org
20 comments
6 participants
participants (6)
-
Davide D'Alto (JIRA) -
Emmanuel Bernard (JIRA)
-
Hardy Ferentschik (JIRA)
-
Marc Schipperheyn (JIRA)
-
Sanne Grinovero (JIRA)
-
Zach Kurey (JIRA)