Well. To all this time...





Hi Emmanuel,


> You lost me :)
> Could you write some code, maybe in a gist.github.com ?


I think I just expressed it overcomplicated. All I was talking about why
I use the QueryBean Interface. It is (currently) needed for hand written 
queries like this:



public BooleanJunction<BooleanJunction> customQuery(
                        BooleanJunction<BooleanJunction> mainBooleanQuery,
                        QueryBuilder queryBuilder) {

        //build your own query, wrap it in a BooleanJunction, and return it 
here.
}


Or for determining the way we have to sort:



        /**
         * @return a custom sort object or null
         */
        public Sort getSort();


or how to facet, etc...


I want for this stuff to move to annotations (maybe) because I don't really like
the fact that I have to implement an Interface for that (and the current 
approach doesn't
allow profiles).



> 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. 


I think they don't scale well in the general case but in this scenario I think 
it's ok.


Look at this:



@Queries(@Query(profile = "notName", must = @Must(subQuery = 
"someNameForTheQuery")))
@SubQueries(@SubQuery(id = "someNameForTheQuery", query = @Query(must = 
@Must(not = true, value = @SearchField(fieldName = "name", propertyName = 
"name")))))



I look at it this way: I lose the easy way to do tree structures, but I gain a 
way to document my query by having to give names to my sub-queries :).


> 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. 



Uhm. I totally forgot to add this functionality in my rewrite (I have rewritten 
most of the code last weekend)
and I implemented a way to pass parameters into QueryTypes. You can even pass 
parameters that are dynamically
determined by stating the property to get its value from. With that you can 
easily do RangeQueryTypes.
If you want me to elaborate on that, I can provide you with an example.


> What do you mean by query nesting by hand?


Consider you have a query like this (again with boolean syntax):


(queryA || queryD) && (queryB || (queryC) || queryE,...


Now you would have to build a BooleanJunction and several subJunctions
and then put them together. I have written that type of code before and
I made some mistakes because I messed up the variable names in my head.


> And how does the annotation approach differs?


In the annotation Version it would look something like this (example from 
above):



@Queries(@Query(must = {
        @Must(subQuery = "queryAOrQueryD"),
        @Must(subQuery = "queryBOrQueryC"),
        @Must(subQuery = "queryE")}))
@SubQueries({
        @SubQuery(id = "queryAOrQueryD", 
                query = @Query(should = {@Should(subQuery = "queryA"), 
@Should(subQuery = "queryD")})
        @SubQuery(id = "queryBOrQueryC",
                query = @Query(should = {@Should(subQuery = "queryB"), 
@Should(subQuery = "queryC")})
        ...
        //define query[A-E] here.
})



Maybe it's because I don't like to work with the Junctions and put them 
together myself,
and maybe it's only me that thinks this would be easier :P.


Martin Braun
martinbraun...@aol.com
www.github.com/s4ke




-----Original Message-----
From: Emmanuel Bernard <emman...@hibernate.org>
To: Martin Braun <martinbraun...@aol.com>
Cc: hibernate-dev <hibernate-dev@lists.jboss.org>
Sent: Mon, Feb 3, 2014 10:22 pm
Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search






On 3 févr. 2014, at 21:57, Martin Braun <martinbraun...@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
martinbraun...@aol.com
www.github.com/s4ke




-----Original Message-----
From: Emmanuel Bernard <emman...@hibernate.org>
To: Martin Braun <martinbraun...@aol.com>
Cc: hibernate-dev <hibernate-dev@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 <martinbraun...@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
> martinbraun...@aol.com
> www.github.com/s4ke
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev




_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Reply via email to