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