1:49 a.m.
Hi Search team,
I have this question for a long time but, this time, having 30 (and
growing) indexed entities inheriting from an abstract class, I thought
I might as well ask about it...
Is there any reason why we can't set the @Indexed annotation on the
abstract class to get all the implementations indexed in their
separate indexes? This way, I wouldn't have to put the annotation on
each implementation and think about adding it each time I extend this
abstract class.
Another painful things that beats me yesterday is that I cannot do:
searchFactory.buildQueryBuilder().forEntity(MyAbstractEntity.class).get();
to build Lucene queries based on the common indexed fields of the
abstract class: I'm forced to use one of the concrete implementation
(and apart that it's not that nice, I'm not that confident I can
choose one that will never be removed from the code base).
Thanks for your feedback.
--
Guillaume
3:51 a.m.
On 10 mai 2012, at 08:49, Guillaume Smet wrote:
Hi Search team,
I have this question for a long time but, this time, having 30 (and
growing) indexed entities inheriting from an abstract class, I thought
I might as well ask about it...
Is there any reason why we can't set the @Indexed annotation on the
abstract class to get all the implementations indexed in their
separate indexes? This way, I wouldn't have to put the annotation on
each implementation and think about adding it each time I extend this
abstract class.
That would go counter to the JPA design I think and to be honest, I like the idea of being
able to not index a given branch of a class hierarchy.
But more importantly, you would require Hibernate Search to scan for all subclasses in the
classpath and I don't want to go anywhere near that.
Another painful things that beats me yesterday is that I cannot do:
searchFactory.buildQueryBuilder().forEntity(MyAbstractEntity.class).get();
to build Lucene queries based on the common indexed fields of the
abstract class: I'm forced to use one of the concrete implementation
(and apart that it's not that nice, I'm not that confident I can
choose one that will never be removed from the code base).
Scratch your own :) itch https://hibernate.onjira.com/browse/HSEARCH-703
This is an issue that has been opened for a while but not addressed by like of motivated
contributors. The solution is fairly simple at first sight.
4:12 a.m.
On Sat, May 12, 2012 at 10:51 AM, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
That would go counter to the JPA design I think and to be honest, I
like the idea of being able to not index a given branch of a class hierarchy.
But more importantly, you would require Hibernate Search to scan for all subclasses in
the classpath and I don't want to go anywhere near that.
Having struggled with the new Servlet 3 stuff allowing pure Java
configuration and having Tomcat scan the whole classpath at startup to
find the information, I can get your point as it adds between 10 and
20 seconds at each startup.
That said, I'm still not a big fan on maintaining at hand @Indexed
annotations on a branch with a lot of subclasses :).
Scratch your own :) itch
https://hibernate.onjira.com/browse/HSEARCH-703
This is an issue that has been opened for a while but not addressed by like of motivated
contributors. The solution is fairly simple at first sight.
Fair enough. I'll give it a try in the next few days.
Thanks for the pointer.
--
Guillaume
5:28 a.m.
> Scratch your own :) itch
https://hibernate.onjira.com/browse/HSEARCH-703
> This is an issue that has been opened for a while but not addressed by like of
motivated contributors. The solution is fairly simple at first sight.
Fair enough. I'll give it a try in the next few days.
Now that is an answer we like to hear :-)
--hardy
5:38 a.m.
On 12 mai 2012, at 12:28, Hardy Ferentschik wrote:
>> Scratch your own :) itch https://hibernate.onjira.com/browse/HSEARCH-703
>> This is an issue that has been opened for a while but not addressed by like of
motivated contributors. The solution is fairly simple at first sight.
>
> Fair enough. I'll give it a try in the next few days.
Now that is an answer we like to hear :-)
Right but it's nothing compared to the smell of fresh pull requests ;)
5:39 a.m.
On 12 mai 2012, at 11:12, Guillaume Smet wrote:
> That would go counter to the JPA design I think and to be honest,
I like the idea of being able to not index a given branch of a class hierarchy.
> But more importantly, you would require Hibernate Search to scan for all subclasses
in the classpath and I don't want to go anywhere near that.
Having struggled with the new Servlet 3 stuff allowing pure Java
configuration and having Tomcat scan the whole classpath at startup to
find the information, I can get your point as it adds between 10 and
20 seconds at each startup.
That said, I'm still not a big fan on maintaining at hand @Indexed
annotations on a branch with a lot of subclasses :).
10-20 seconds? For how many classes in your app ?! Use a real app server man, we worked
hard to reduce this time in JBoss AS :)
7:17 a.m.
On Sat, May 12, 2012 at 12:39 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
10-20 seconds? For how many classes in your app ?!
Probably quite a lot because it scans the whole classpath but nothing
weird as our applications are "just" Spring-*/Hibernate-*/Wicket
applications.
The scan in Tomcat isn't really optimized in terms of IO (a lot of
random IO throughout all the jars and it would probably be better with
sequential access). I wanted to give a shot at optimizing that but I
haven't found the time yet.
The Servlet 3 + Java configuration cost was really unacceptable (and
buggy) before Tomcat 7.0.26 (+ 30-40 seconds on each startup) where
the scan for interfaces and annotations configuring the servlet
environment was entirely rewritten.
Use a real app server man, we worked hard to reduce this time in
JBoss AS :)
Yeah, well, last time I checked, it wasn't so amazing but it was a
long time ago.
Without using the new Servlet 3 java configuration, Tomcat + our
applications usually start in 10-15 seconds in our dev environment
(and even less on our servers) so it's quite good.
--
Guillaume
4561
days inactive
4565
days old
6 comments
3 participants
participants (3)
-
Emmanuel Bernard -
Guillaume Smet -
Hardy Ferentschik