[ORM] Depending on jboss-logging-annotations ?
by Sanne Grinovero
I see I'm now having a dependency pulled in by maven to:
org.jboss.logging:jboss-logging-annotations
This is being included as a transitive dependency via each of:
- org.hibernate:hibernate-core:jar:4.3.1.Final
- org.hibernate:hibernate-testing:jar:4.3.1.Final
- org.hibernate:hibernate-entitymanager:jar:4.3.1.Final
- org.hibernate.common:hibernate-commons-annotations:jar:4.0.4.Final
I assume this is a simple mistake in the build settings? Or do we
actually need this at runtime?
Sanne
12 years, 1 month
Re: [hibernate-dev] Feature Proposal for Hibernate Search
by Martin Braun
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
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 10:22 pm
Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search
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
12 years, 1 month
Re: [hibernate-dev] Feature Proposal for Hibernate Search
by 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(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
12 years, 1 month
Re: [hibernate-dev] HSEARCH Discussions on schedule for Hibernate Search 5.0
by Emmanuel Bernard
Resending as I screwed up the Hibernate Dev email.
On Mon 2014-02-03 14:28, Emmanuel Bernard wrote:
> Hello Hardy, Sanne and all,
>
> I think it's time to discuss the schedule we want for Hibernate Search
> 5. While we don't usually use time boxing, it's still useful to try and
> shoot for a rough capped timing.
>
> I have proposed several options for the meeting on Doodle, make sure to
> set the time zone correctly.
>
> http://doodle.com/8mfadig97447bb4s#table
>
> Anyone is welcome to join of course and we will try to accommodate for
> most. But the propose schedules tend to be European friendly and if
> possible I'd love to get this meeting done by Wed.
>
> Emmanuel
12 years, 1 month
Re: [hibernate-dev] Feature Proposal for Hibernate Search
by Martin Braun
Hi again,
hardy is right. Here is a longer version of the proposal (that is more discussion friendly):
> 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.
Okay. Let me explain my idea with this little example:
We have a fulltext enabled search that takes multiple parameters. For easier usage we have a parameter-wrapper similar to this:
public class PlaceQueryBean {
private String name;
public String getName() {
return this.name;
}
public void setName(String name) {
this.name = name;
}
}
This is just a shortened version with only one parameter. But if we wanted to write a Hibernate Search Query, it would look similar to this:
queryBuilder.term().onField("name").matching(queryBean.getName())...
As the parameters get more the query gets bigger and bigger and you have to "manually" retrieve the data out of the Query-Bean (which is easier to use than vanilla Lucene queries, but you are still required to write a lot of boilerplate code).
In my Extension a query like that would only have to be added to the class via annotations. You only have to write the query-structure and lose the hand written queries. And another big plus: The query logic is in the exact same spot where the data is (and not in the service).
@Queries(@Query(must = @Must(@SearchField(fieldName = "name", propertyName = "name"))))
public class PlaceQueryBean extends BaseQueryBean {
private String name;
public String getName() {
return this.name;
}
public void setName(String name) {
this.name = name;
}
}
> Your approach is bean driven, where the bean defines the query parameters you
> have for a given query.
Yes that's correct, but I am thinking which methods of the BeanInterface can be moved to the Annotations.
And by these "callback"-methods from the Searcher you can still build normal Hibernate-Search queries.
> You also created a set of annotations which allow you to specify the query via
> annotations on the bean.
Yes.
> 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?
Yes.
> How would you provide multiple parameters
What do you mean by that? Normally you would pass a Bean that has a list of values. Which junction
to use there is specified in the SearchField Annotation via the betweenValues() property.
> and how do you select
> a given query in a bean (it seems you envision the possibility to provide more
> than one).
Yes. You can pass a optional profile value to the Searcher.
> What are your plans? Can you maybe share your vision for this extension? How
> would you envision to
> integrate it with Search?
I plan on moving most of the stuff that has to be hand-written to bean declarations (Sorts, Filters, etc.)
Do you need to modify core functionality or could this
> be an optional “search” module?
I don't think I'd need to modify any core functionality.
I hope I have done better this time :).
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: Mon, Feb 3, 2014 9:13 pm
Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search
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
12 years, 1 month
postgres dialect and wildfly
by Bill Burke
Hey,
My Hibernate knowledge is really dated, but, within a Wildfly/AS7/JPA
deployment don't you still have to specify the SQL dialect in your
persistence.xml? Or is this automatically figured out now?
I have a user that is seeing postgres org.postgresql.util.PSQLException:
ERROR: operator does not exist
Errors and I thought setting the dialect might yelp.
Thanks.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years, 1 month
OGM depending on ORM 4.3
by Emmanuel Bernard
To follow up on the PR migrating OGM to ORM 4.3. I think it is the right
thing to do but I wonder whether we should do a tag / release of
Hibernate OGM before that. So that people still using the JPA 2.0 series
have a final version and a point for fork.
What has happened between the latest OGM version and now - aside from a
long time that is :)
Emmanuel
12 years, 1 month
[OGM] Behavior of GenerationType.IDENTITY with OGM
by Gunnar Morling
Hi,
While reviewing the PR for batch operations in OGM [1], I took some time to
better understand OGM's approaches for id generation.
Now I'm wondering about how GenerationType.IDENTITY is implemented. The
corresponding generator (OgmIdentityGenerator) just delegates to a
table-based strategy, so an id is always pre-allocated and then passed into
the dialect when creating a tuple.
I think it would be nice to have proper support for server-generated ids,
in particular since some stores return the inserted id directly from the
insert operation, i.e. without requiring another read.
For the time being, as the current implementation doesn't really adhere to
the semantics of GenerationType.IDENTITY, should we raise an error when
using it instead of silently using another strategy?
Thoughts?
--Gunnar
[1] https://hibernate.atlassian.net/browse/OGM-175
12 years, 1 month
