[hibernate-dev] Feature Proposal for Hibernate Search

[Martin Braun]

... 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 at aol.com
www.github.com/s4ke




-----Original Message-----
From: Hardy Ferentschik <hardy at hibernate.org>
To: Martin Braun <martinbraun123 at aol.com>
Cc: Hibernate <hibernate-dev at 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 at 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