12:22 p.m.
... forgot to send it to all again.
That would be cool
-> Next E-Mail
I have to say that his boggles my mind. You have to do a lot of mind
work and
jumping forward and backward to put things
together. I guess we can agree that this is not a silver bullet which makes
writing queries objectively easier to write.
To be honest, yes you have to jump
around. But: small queries (with no nesting)
don't need any of this SubQuery stuff. And you can reuse subqueries (which I
particularly like).
Then again your point about the silver bullet is kinda right. But I think small queries
(again, without nesting)
ARE easier to write like that and if you need more complicated queries it's more
convenient
or at least as convenient as working with BooleanJunctions (because of the way you can
reuse stuff).
Maybe the example wasn't written completely right, because a better version would be:
@Queries(@Query(must = {
@Must(subQuery = "queryAOrQueryD"),
@Must(subQuery = "queryBOrQueryC"),
@Must(@SearchField(searchField = "someFieldE", propertyName =
"some.propertyE"))}))
@SubQueries({
@SubQuery(id = "queryAOrQueryD",
query = @Query(should = {@Should(@SearchField(searchField = "someFieldA",
propertyName = "some.propertyA")),
@Should(@SearchField(searchField = "someFieldD", propertyName =
"some.propertyD"))})
@SubQuery(id = "queryBOrQueryC",
query = @Query(should = {
@Should(@SearchField(searchField = "someFieldB", propertyName =
"some.propertyB")),
@Should(@SearchField(searchField = "someFieldC", propertyName =
"some.propertyC"))})
})
(only really nested queries have to be declared in a SubQuery). Now the mindjumps are not
as big I think.
But yes, if you need highly nested queries this is not the way to go. This is the reason I
want to provide
users that don't want to do extreme sport with their mind with the customQuery(...)
Method where you can
either write native Lucene Queries or Hibernate-Search DSL queries and then add them to
the main query.
Well, you still have to put things together, just in annotation in
this case.
Well, yes. But in a more structured way I think.
Looping back to Emmanuel’s initial idea, maybe a combination of DSL
and
parameter holder would be a better way to go.
I could imagine that would could drop the various ‘matching’ clauses and instead
in the end just pass the parameter bean to
createQuery. Basically, instead of:
But then you'd lose the part where your
data is exactly with your parameter-wrapper.
Martin Braun
martinbraun123(a)aol.com
www.github.com/s4ke
-----Original Message-----
From: Hardy Ferentschik <hardy(a)hibernate.org>
To: Martin Braun <martinbraun123(a)aol.com>
Cc: Hibernate <hibernate-dev(a)lists.jboss.org>
Sent: Tue, Feb 4, 2014 11:56 am
Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search
On 4 Jan 2014, at 10:24, Martin Braun <martinbraun123(a)aol.com> wrote:
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.
That would be cool.
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.
})
I have to say that his boggles my mind. You have to do a lot of mind work and
jumping forward and backward to put things
together. I guess we can agree that this is not a silver bullet which makes
writing queries objectively easier to write.
Maybe it's because I don't like to work with the Junctions
and put them
together myself,
Well, you still have to put things together, just in annotation in this case.
Looping back to Emmanuel’s initial idea, maybe a combination of DSL and
parameter holder would be a better way to go.
I could imagine that would could drop the various ‘matching’ clauses and instead
in the end just pass the parameter bean to
createQuery. Basically, instead of:
Query query = monthQb
.keyword()
.fuzzy()
.withThreshold( .8f )
.withPrefixLength( 1 )
.onField( "mythology" )
.matching( "calder” )
...
.createQuery();
one would write something like:
Query query = monthQb
.keyword()
.fuzzy()
.withThreshold( .8f )
.withPrefixLength( 1 )
.onField( "mythology" )
…
.createQuery(paramterWrapper);
—Hardy