Hi, Just out of interest, what are the use cases for such a serialized form? Is this intended to be written by humans or other applications? --Gunnar 2013/6/11 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > Hey everyone, > > Sanne and I discussed Hibernate Search queries and serialization in > general. I did play around that to represent Hibernate Search DSL > queries into JSON. > > https://gist.github.com/emmanuelbernard/5760676 > > It is a very first draft (not reviewed). What is really nice is that I did > not have to > do much adaptation, the Query DSL is expressive enough to have a one to > one port thanks to its context nature. > > I did not work on some of the quirk cases nor tried to optimize the > "80%" use case. > > A nice effect is that I manage to unify the FullTextQuery (including the > types filtering), the lucene query part, the faceting definitions and > the faceting selection. > > Let me know what you think. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

In the end there is always a human (so far) but think of it as used in the same way SQL is. SQL is sued by both humans and programs (ORMs). Emmanuel On Wed 2013-06-12 15:03, Gunnar Morling wrote: > Hi, > > Just out of interest, what are the use cases for such a serialized form? Is > this intended to be written by humans or other applications? > > --Gunnar > > > > > 2013/6/11 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > > > Hey everyone, > > > > Sanne and I discussed Hibernate Search queries and serialization in > > general. I did play around that to represent Hibernate Search DSL > > queries into JSON. > > > > https://gist.github.com/emmanuelbernard/5760676 > > > > It is a very first draft (not reviewed). What is really nice is that I did > > not have to > > do much adaptation, the Query DSL is expressive enough to have a one to > > one port thanks to its context nature. > > > > I did not work on some of the quirk cases nor tried to optimize the > > "80%" use case. > > > > A nice effect is that I manage to unify the FullTextQuery (including the > > types filtering), the lucene query part, the faceting definitions and > > the faceting selection. > > > > Let me know what you think. > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >

On 13 Jan 2013, at 8:47 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > Would creating a "real" query language instead of a serialized object > representation make sense then? You mean the Lucene query language - http://lucene.apache.org/core/old_versioned_docs/versions/3_4_0/querypars...) In the end it comes down to that.

What would the purpose of a new query language be? I guess it would be more object centric, but is this relevant for a user?

> This would allow for a conciser syntax, making it easier to write (that's > why I asked who would be writing such queries), but probably it'd be more > work to create such a language. I guess a sub-set of JPQL would work for > some parts, but additional elements would be needed for facets etc. I just don't see users of a finished app being exposed to such query functionality. I see the JSON representation just as a way to serialise the query. To which means I am not sure at the moment.

--Hardy

On 13 Jan 2013, at 2:11 PM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > 2013/6/13 Hardy Ferentschik <hardy(a)hibernate.org&gt; > > On 13 Jan 2013, at 8:47 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > > > Would creating a "real" query language instead of a serialized object > > representation make sense then? > > You mean the Lucene query language - http://lucene.apache.org/core/old_versioned_docs/versions/3_4_0/querypars... ;-) > In the end it comes down to that. > > Maybe, if that has everything needed, why not? Or is a goal to hide the fact that Lucene is used underneath? > > What would the purpose of a new query language be? I guess it would be more object centric, but is this relevant for a user? > > What's the purpose of the JSON notation? I think for a user its nicer to express a query in a dedicated query language instead of a general-purpose object serialization format. As it is nicer for a human to express queries in say HQL or SQL instead of describing e.g. a "HQL object" in JSON or XML. If this is going to be used by application code, it probably doesn't make a big difference. > > I guess I just don't yet really understand what's the use case behind. Right, that's what I am also trying to see/find.

>> Right, that's what I am also trying to see/find. > > Sorry, I got confused by your question initially. The query language is not for an > end-user, it is for developers or machines. So why would a developer use it? One point of the DSL was to have type safe queries and now we want him to write JSON strings? Also, what is the result of the query? Entities in JSON format? I just don't see when a developer would like to use this query format. Maybe for prototyping or ad hoc experimenting with some queries. How much easier is that, however, compared to a simple unit test?

> JSON here was used as an example of serializable format. The problem I > was trying to address is to serialize the query in a platform agnostic > way. Why not use Avro again? That's how we serialise the Work instances. Why now introduce JSON?