12:08 p.m.
Hi,
I am currently working on a new way to query in Hibernate Search. It's not finished,
but
it already works. I am planning on extending the functionality a lot in the future and
I thought this could be a nice addition to Hibernate Search. What do you think?
https://github.com/s4ke/HibernateSearchQueryExtension
Martin Braun
martinbraun123(a)aol.com
www.github.com/s4ke
2:13 p.m.
Hi Martin,
great that you like Hibernate Search and want to make it even easier to use.
On 3 Jan 2014, at 19:08, Martin Braun <martinbraun123(a)aol.com> wrote:
I am currently working on a new way to query in Hibernate Search.
It's not finished, but
it already works.
I had a quick look at the code, but for the sake of discussion, it would be great if you
could outline
your approach in an email. Maybe with some example code? It would make it much easier for
everyone
interested to see what you want to achieve.
Let me try to sum your approach up from what I read in the readme and glancing at the
code. Please
correct me from where I am wrong.
Your approach is bean driven, where the bean defines the query parameters you have for a
given query.
You also created a set of annotations which allow you to specify the query via annotations
on the bean.
When you create a Searcher you pass it the bean and the parameter values. From there is
query is build
and executed for you. Is this correct? How would you provide multiple parameters and how
do you select
a given query in a bean (it seems you envision the possibility to provide more than one).
Is this correct?
I am planning on extending the functionality a lot in the future
What are your plans? Can you maybe share your vision for this extension? How would you
envision to
integrate it with Search? Do you need to modify core functionality or could this be an
optional “search” module?
—Hardy
2:45 p.m.
Hi Martin,
That's interesting. I have a couple of questions for you.
What is the notion of profile and when would you use it?
When do you need and use sub query ids?
The issue you had was to map getters to query parameters in an easier way than currently
possible, correct? It reminds me a little bit of the Example query with a parameter twist.
I have to admit, I am a bit skeptical on a few things:
- having to extend a technical class
- I don't think annotations are the best way to express queries but you probably have
your reasons, so let's discuss them :)
Have you explored the ability to write the query programmatically while still making use
of the getter binding? I can imagine we could update the DSL to accept the parameters
holder and have them injected.
I wonder if literally an Example API would address your use cases ?
Thanks the first thoughts
Emmanuel
On 3 févr. 2014, at 19:08, Martin Braun
<martinbraun123(a)aol.com> wrote:
Hi,
I am currently working on a new way to query in Hibernate Search. It's not finished,
but
it already works. I am planning on extending the functionality a lot in the future and
I thought this could be a nice addition to Hibernate Search. What do you think?
https://github.com/s4ke/HibernateSearchQueryExtension
Martin Braun
martinbraun123(a)aol.com
www.github.com/s4ke
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2:57 p.m.
HI Emmanuel,
Hi Martin,
That's interesting. I have a couple of questions for you.
What is the notion of profile and when would you use it?
This can be used when
you'd like to be able to use the same queryBean in different contexts
sou you don't have to write a different Bean if you only need a query that's a
little bit different.
When do you need and use sub query ids?
This is needed if you
want to do queries like this (explained in boolean-logic):
(queryA && (!queryB || queryC)).
You can get as complicated as you want with this. These SubQueries are mainly used
because
Java doesn't allow recursiveness in Annotations.
The issue you had was to map getters to query parameters in an easier
way than
currently possible, correct? It reminds me a little bit of the Example query
with a parameter twist.
Which one are you talking about?
I have to admit, I am a bit skeptical on a few things:
- having to extend a technical class
I am too, As stated in the e-mail before I
want to get away from that design but I still
want to be able to write queries myself if I want to. This can be done with Annotations
on
Method-Level or with QueryProviders in an extra Annotation on the Type-Level.
- I don't think annotations are the best way to express queries
but you probably
have your reasons, so let's discuss them :)
Why? I think it's not hard to
read an you have the query right with your ParameterWrapper-class which holds your data.
Have you explored the ability to write the query programmatically
while still
making use of the getter binding? I can imagine we could update the DSL to
accept the parameters holder and have them injected.
I think that would be
possible, but then you would still have to handle the
query nesting and such by hand and that code would be more complicated to use (but easier
to debug, tbh).
I wonder if literally an Example API would address your use cases ?
What do you mean by that?
Martin Braun
martinbraun123(a)aol.com
www.github.com/s4ke
-----Original Message-----
From: Emmanuel Bernard <emmanuel(a)hibernate.org>
To: Martin Braun <martinbraun123(a)aol.com>
Cc: hibernate-dev <hibernate-dev(a)lists.jboss.org>
Sent: Mon, Feb 3, 2014 9:45 pm
Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search
Hi Martin,
That's interesting. I have a couple of questions for you.
What is the notion of profile and when would you use it?
When do you need and use sub query ids?
The issue you had was to map getters to query parameters in an easier way than
currently possible, correct? It reminds me a little bit of the Example query
with a parameter twist.
I have to admit, I am a bit skeptical on a few things:
- having to extend a technical class
- I don't think annotations are the best way to express queries but you probably
have your reasons, so let's discuss them :)
Have you explored the ability to write the query programmatically while still
making use of the getter binding? I can imagine we could update the DSL to
accept the parameters holder and have them injected.
I wonder if literally an Example API would address your use cases ?
Thanks the first thoughts
Emmanuel
On 3 févr. 2014, at 19:08, Martin Braun
<martinbraun123(a)aol.com> wrote:
Hi,
I am currently working on a new way to query in Hibernate Search. It's not
finished, but
it already works. I am planning on extending the functionality a lot
in the
future and
I thought this could be a nice addition to Hibernate Search. What do
you
think?
https://github.com/s4ke/HibernateSearchQueryExtension
Martin Braun
martinbraun123(a)aol.com
www.github.com/s4ke
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:04 p.m.
The example API I was thinking about is
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#querycr...
On 3 févr. 2014, at 21:57, Martin Braun
<martinbraun123(a)aol.com> wrote:
HI Emmanuel,
Hi Martin,
> That's interesting. I have a couple of questions for you.
> What is the notion of profile and when would you use it?
This can be used when you'd like to be able to use the same queryBean in different
contexts
sou you don't have to write a different Bean if you only need a query that's a
little bit different.
> When do you need and use sub query ids?
This is needed if you want to do queries like this (explained in boolean-logic):
(queryA && (!queryB || queryC)).
You can get as complicated as you want with this. These SubQueries are mainly used
because
Java doesn't allow recursiveness in Annotations.
> The issue you had was to map getters to query parameters in an easier way than
> currently possible, correct? It reminds me a little bit of the Example query
> with a parameter twist.
Which one are you talking about?
> I have to admit, I am a bit skeptical on a few things:
> - having to extend a technical class
I am too, As stated in the e-mail before I want to get away from that design but I still
want to be able to write queries myself if I want to. This can be done with Annotations
on
Method-Level or with QueryProviders in an extra Annotation on the Type-Level.
> - I don't think annotations are the best way to express queries but you probably
> have your reasons, so let's discuss them :)
Why? I think it's not hard to read an you have the query right with your
ParameterWrapper-class which holds your data.
> Have you explored the ability to write the query programmatically while still
> making use of the getter binding? I can imagine we could update the DSL to
> accept the parameters holder and have them injected.
I think that would be possible, but then you would still have to handle the
query nesting and such by hand and that code would be more complicated to use (but easier
to debug, tbh).
> I wonder if literally an Example API would address your use cases ?
What do you mean by that?
Martin Braun
martinbraun123(a)aol.com
www.github.com/s4ke
-----Original Message-----
From: Emmanuel Bernard <emmanuel(a)hibernate.org>
To: Martin Braun <martinbraun123(a)aol.com>
Cc: hibernate-dev <hibernate-dev(a)lists.jboss.org>
Sent: Mon, Feb 3, 2014 9:45 pm
Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search
Hi Martin,
That's interesting. I have a couple of questions for you.
What is the notion of profile and when would you use it?
When do you need and use sub query ids?
The issue you had was to map getters to query parameters in an easier way than
currently possible, correct? It reminds me a little bit of the Example query
with a parameter twist.
I have to admit, I am a bit skeptical on a few things:
- having to extend a technical class
- I don't think annotations are the best way to express queries but you probably
have your reasons, so let's discuss them :)
Have you explored the ability to write the query programmatically while still
making use of the getter binding? I can imagine we could update the DSL to
accept the parameters holder and have them injected.
I wonder if literally an Example API would address your use cases ?
Thanks the first thoughts
Emmanuel
> On 3 févr. 2014, at 19:08, Martin Braun <martinbraun123(a)aol.com> wrote:
>
>
> Hi,
>
>
> I am currently working on a new way to query in Hibernate Search. It's not
finished, but
> it already works. I am planning on extending the functionality a lot in the
future and
> I thought this could be a nice addition to Hibernate Search. What do you
think?
>
>
> https://github.com/s4ke/HibernateSearchQueryExtension
>
>
> Martin Braun
> martinbraun123(a)aol.com
> www.github.com/s4ke
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:22 p.m.
On 3 févr. 2014, at 21:57, Martin Braun
<martinbraun123(a)aol.com> wrote:
> I have to admit, I am a bit skeptical on a few things:
> - having to extend a technical class
I am too, As stated in the e-mail before I want to get away from that design but I still
want to be able to write queries myself if I want to. This can be done with Annotations
on
Method-Level or with QueryProviders in an extra Annotation on the Type-Level.
You lost me :)
Could you write some code, maybe in a gist.github.com ?
> - I don't think annotations are the best way to express
queries but you probably
> have your reasons, so let's discuss them :)
Why? I think it's not hard to read an you have the query right with your
ParameterWrapper-class which holds your data.
Indeed I like that both the query and the parameter values are hosted on the same class.
And I would have the programmatic query expressed on that class. (I know it goes against
my later proposal to provide params support in the DSL itself but I explore multiple
routes :) ). This also solves another problem we have today of propagating the entity type
to the creation of the full text query.
But annotations in my opinion don't scale very well for tree structures. Composition,
lack of polymorphism are also not easy / elegant in annotations.
You can see that you had to break the sub queries with string references. And I am not
sure how you will be able to express other query types that we have like range, spatial
etc. I might be wrong, so it's worth trying. But even then, if we had one new query
type, we have to also add an equivalent annotation or add new fields to an existing one.
> Have you explored the ability to write the query
programmatically while still
> making use of the getter binding? I can imagine we could update the DSL to
> accept the parameters holder and have them injected.
I think that would be possible, but then you would still have to handle the
query nesting and such by hand and that code would be more complicated to use (but easier
to debug, tbh).
What do you mean by query nesting by hand? And how does the annotation approach differs?
> I wonder if literally an Example API would address your use
cases ?
What do you mean by that?
Martin Braun
martinbraun123(a)aol.com
www.github.com/s4ke
-----Original Message-----
From: Emmanuel Bernard <emmanuel(a)hibernate.org>
To: Martin Braun <martinbraun123(a)aol.com>
Cc: hibernate-dev <hibernate-dev(a)lists.jboss.org>
Sent: Mon, Feb 3, 2014 9:45 pm
Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search
Hi Martin,
That's interesting. I have a couple of questions for you.
What is the notion of profile and when would you use it?
When do you need and use sub query ids?
The issue you had was to map getters to query parameters in an easier way than
currently possible, correct? It reminds me a little bit of the Example query
with a parameter twist.
I have to admit, I am a bit skeptical on a few things:
- having to extend a technical class
- I don't think annotations are the best way to express queries but you probably
have your reasons, so let's discuss them :)
Have you explored the ability to write the query programmatically while still
making use of the getter binding? I can imagine we could update the DSL to
accept the parameters holder and have them injected.
I wonder if literally an Example API would address your use cases ?
Thanks the first thoughts
Emmanuel
> On 3 févr. 2014, at 19:08, Martin Braun <martinbraun123(a)aol.com> wrote:
>
>
> Hi,
>
>
> I am currently working on a new way to query in Hibernate Search. It's not
finished, but
> it already works. I am planning on extending the functionality a lot in the
future and
> I thought this could be a nice addition to Hibernate Search. What do you
think?
>
>
> https://github.com/s4ke/HibernateSearchQueryExtension
>
>
> Martin Braun
> martinbraun123(a)aol.com
> www.github.com/s4ke
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:39 a.m.
On 3 Jan 2014, at 22:22, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
>> - I don't think annotations are the best way to express
queries but you probably
>> have your reasons, so let's discuss them :)
> Why? I think it's not hard to read an you have the query right with your
ParameterWrapper-class which holds your data.
Indeed I like that both the query and the parameter values are hosted on the same class.
That’s the part I kind of like here as well
And I would have the programmatic query expressed on that class.
That’s an interesting thought.
But annotations in my opinion don't scale very well for tree
structures.
I share Emmanuel’s concern on this one. I think you would get some quite nasty constructs,
once you want to provide the full query capabilities.
Whether or not annotations defined queries would then be easier to read than DSL queries
becomes then a matter of taste.
I for example am still holding on to good old native Lucene queries.
For a pure dev point, supporting all these different query capabilities is of course a
pain, since the work you have to do for each new feature keep growing.
—Hardy
3948
days inactive
3949
days old
6 comments
3 participants
participants (3)
-
Emmanuel Bernard -
Hardy Ferentschik -
Martin Braun