11:22 a.m.
Hi,
We would like to declare our global @AnalyzerDefs on a class which
isn't a specific entity.
For the @TypeDefs of Hibernate, we do it by declaring the @TypeDefs on
a class annotated with @MappedSuperClass but with @AnalyzerDefs, we
are forced to declare them on a concrete @Entity.
Is this an oversight or something due to the way the initialization of
Hibernate Search is done and we cannot change?
I know it's only cosmetic but it's a bit ugly to have a dummy entity
and a dummy table in our core framework just to be able to declare
global @AnalyzerDefs.
Thanks for your feedback.
--
Guillaume
11:36 a.m.
On 20 Jan 2013, at 6:22 PM, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
Hi,
We would like to declare our global @AnalyzerDefs on a class which
isn't a specific entity.
For the @TypeDefs of Hibernate, we do it by declaring the @TypeDefs on
a class annotated with @MappedSuperClass but with @AnalyzerDefs, we
are forced to declare them on a concrete @Entity.
On an @Entity? Don't you mean @Indexed?
@Entity is a JPA annotation and @AnalyzerDefs is Hibernate Search annotation.
We don't process (except @Id) JPA annotations in Search.
--Hardy
11:39 a.m.
Hi Guillame,
reusing a @MappedSuperClass annotated entity sounds like a workaround
rather than the proper solution.
But I see your point on defining the global analyzers in a centralized
place rather than have them scattered on entities; question is if we
can do better?
There is a property to define the default analyzer:
_hibernate.search.analyzer_ . Maybe we could introduce a property to
point to a class containing all analyzers?
hibernate.search.global_analyzers = com.example.analisys.GlobalSearchAnalyzers
(I'm not liking my own idea about a property, just writing down some
ideas to the get the brainstorming started)
Ideally I'd even like to deprecate defining global analyzers on
@Indexed entities: they really should be used only in the scope of the
entity itself, and I would like to propose this change for 5.0 but
indeed we would first need to clarify where the global annotations
should be defined.
Hardy, while moving to Jandex would it be possible - and efficient -
for us to just find all @AnalyzerDefs on the user classpath (without
these necessarily needing to be mapped entities) ?
Sanne
On 20 June 2013 17:22, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
Hi,
We would like to declare our global @AnalyzerDefs on a class which
isn't a specific entity.
For the @TypeDefs of Hibernate, we do it by declaring the @TypeDefs on
a class annotated with @MappedSuperClass but with @AnalyzerDefs, we
are forced to declare them on a concrete @Entity.
Is this an oversight or something due to the way the initialization of
Hibernate Search is done and we cannot change?
I know it's only cosmetic but it's a bit ugly to have a dummy entity
and a dummy table in our core framework just to be able to declare
global @AnalyzerDefs.
Thanks for your feedback.
--
Guillaume
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:41 a.m.
On 20 Jan 2013, at 6:39 PM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
Hardy, while moving to Jandex would it be possible - and efficient -
for us to just find all @AnalyzerDefs on the user classpath (without
these necessarily needing to be mapped entities) ?
Absolutely!
--Hardy
11:45 a.m.
Great, so maybe we should just do that.
BTW, slightly unrelated, but in the same style it always bothered me
that @NamedQuery definitions need to be specified on entities.
Granted they often relate to a specific entity, but not always, and in
some cases they are better maintained close to their business logic,
or organised by functionality.
Sanne
On 20 June 2013 17:41, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On 20 Jan 2013, at 6:39 PM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
> Hardy, while moving to Jandex would it be possible - and efficient -
> for us to just find all @AnalyzerDefs on the user classpath (without
> these necessarily needing to be mapped entities) ?
Absolutely!
--Hardy
4:33 a.m.
On 21 Jan 2013, at 12:17 AM, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
Hi Sanne,
On Thu, Jun 20, 2013 at 6:45 PM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
> Great, so maybe we should just do that.
Yep, looks like a good idea and would be far cleaner.
+1 once we use Jandex we can fore sure do that.
On the other hand, you are saying that you are using Hibernate Search which means that
you have at last one @Indexed class. Why not add the definitions there? Would that not be
a
logical place anyways?
Another thought, I wonder whether you could use the programmatic API to just define the
analyser
definition on a non indexed entity?
--Hardy
5:17 a.m.
I've actually found a flaw in my suggestion: a scan of all user
provided classes might not be desirable.
For one, someone might have some unintended dependencies which happen
to include such an @AnalyzerDef, which could conflict with some
definition name being used elsewhere and this is not always easy to
control.
Ok that might be far fetched, but there is a stronger use case:
some applications use multiple entity sets, mixing them in various
Persistence Units. Those users typically rely on the configuration
capabilities of JPA / Hibernate to disable annotation scanning and
list entities explicitly, jars explicitly, packages, etc..
When relying on @MappedSuperClass or other *known* entities, we
inherently take advantage of these isolation features to nicely build
just what is expected and no more; if we where to scan all user
classpath without these restrictions, the user wouldn't have an option
to specify some kind of filtering when needed.
Assuming we don't want to be too coupled to ORM - Search integrates
with more - then we need an alternative filtering option, and we would
need to reimplement such logic.
Guillaume, could you clarify the use case once more? I am assuming it
was all about a cleaner code organization; in that case wouldn't it be
enough to specify a single class to be scanned for the global analyzer
definitions?
Sanne
On 21 June 2013 10:33, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On 21 Jan 2013, at 12:17 AM, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
> Hi Sanne,
>
> On Thu, Jun 20, 2013 at 6:45 PM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
>> Great, so maybe we should just do that.
>
> Yep, looks like a good idea and would be far cleaner.
+1 once we use Jandex we can fore sure do that.
On the other hand, you are saying that you are using Hibernate Search which means that
you have at last one @Indexed class. Why not add the definitions there? Would that not be
a
logical place anyways?
Another thought, I wonder whether you could use the programmatic API to just define the
analyser
definition on a non indexed entity?
--Hardy
7:26 a.m.
On Fri, Jun 21, 2013 at 12:17 PM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
Guillaume, could you clarify the use case once more? I am assuming
it
was all about a cleaner code organization; in that case wouldn't it be
enough to specify a single class to be scanned for the global analyzer
definitions?
You assume correctly.
Our core library doesn't contain any entity and I want to declare the
@AnalyzerDefs in this library to be able to use them everywhere.
Currently, we created a dummy entity to be able to do so. The fact is
that it creates a table in the database which is not very compelling.
I agree that a @MappedSuperClass would be an hack too, but it's less
ugly than an @Entity.
So scanning a single class would be enough, at least for our needs, as
we centralize all our global @AnalyzerDefs here.
--
Guillaume
7:35 a.m.
On 21 Jan 2013, at 2:26 PM, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
On Fri, Jun 21, 2013 at 12:17 PM, Sanne Grinovero
<sanne(a)hibernate.org> wrote:
> Guillaume, could you clarify the use case once more? I am assuming it
> was all about a cleaner code organization; in that case wouldn't it be
> enough to specify a single class to be scanned for the global analyzer
> definitions?
You assume correctly.
Our core library doesn't contain any entity and I want to declare the
@AnalyzerDefs in this library to be able to use them everywhere.
Again, I still don't see the connection between @Entity and @AnalyzerDefs.
How does you library look like and what do you want to provide. Can you provide
an example. Does your library contain an indexed type? Are you using Search in
conjunction with ORM?
Currently, we created a dummy entity to be able to do so. The fact
is
that it creates a table in the database which is not very compelling.
Create a dummy class with @Indexed, or is that not working?
--Hardy
7:46 a.m.
On Fri, Jun 21, 2013 at 2:35 PM, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
Again, I still don't see the connection between @Entity and
@AnalyzerDefs.
How does you library look like and what do you want to provide. Can you provide
an example. Does your library contain an indexed type? Are you using Search in
conjunction with ORM?
Yes, I do use ORM. Well, the only connection is that if I add an
@Entity annotation, it works. If I don't, it doesn't.
But I agree with you that I would prefer no connection at all :).
> Currently, we created a dummy entity to be able to do so. The
fact is
> that it creates a table in the database which is not very compelling.
Create a dummy class with @Indexed, or is that not working?
No, it doesn't. My point is that @AnalyzerDefs discovery is tied up to
having an @Entity annotation on the class. At least, when you have ORM
in the way.
I tested with:
- @Indexed -> doesn't work
- @MappedSuperClass -> doesn't work
- @Entity without @Indexed -> works like a charm
I haven't looked at the code yet, I asked the question before digging
too much into it.
--
Guillaume
9:52 a.m.
To me the real answer is to the programmatic API and add a
programmatic mapping factory to your configuration.
See Example 4.28. Use a mapping factory in
http://docs.jboss.org/hibernate/search/4.4/reference/en-US/html_single/#h...
On Thu 2013-06-20 18:22, Guillaume Smet wrote:
Hi,
We would like to declare our global @AnalyzerDefs on a class which
isn't a specific entity.
For the @TypeDefs of Hibernate, we do it by declaring the @TypeDefs on
a class annotated with @MappedSuperClass but with @AnalyzerDefs, we
are forced to declare them on a concrete @Entity.
Is this an oversight or something due to the way the initialization of
Hibernate Search is done and we cannot change?
I know it's only cosmetic but it's a bit ugly to have a dummy entity
and a dummy table in our core framework just to be able to declare
global @AnalyzerDefs.
Thanks for your feedback.
--
Guillaume
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:59 a.m.
Hi Emmanuel,
On Wed, Aug 21, 2013 at 4:52 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
To me the real answer is to the programmatic API and add a
programmatic mapping factory to your configuration.
See Example 4.28. Use a mapping factory in
http://docs.jboss.org/hibernate/search/4.4/reference/en-US/html_single/#h...
Oh, nice. I haven't thought of using this but it looks like a good idea.
Thanks for the tip.
--
Guillaume
4140
days inactive
4203
days old
12 comments
4 participants
participants (4)
-
Emmanuel Bernard -
Guillaume Smet -
Hardy Ferentschik -
Sanne Grinovero