[infinispan-dev] JSON version of Hibernate Search query

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] JSON version of Hibernate Search query

Emmanuel Bernard
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.
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] [hibernate-dev] JSON version of Hibernate Search query

Gunnar Morling
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 <[hidden email]>
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/hibernate-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] [hibernate-dev] JSON version of Hibernate Search query

Sanne Grinovero-2
I think you could intend it like the SQL traditionally did for
relational databases: it's primarily intended to be consumed by other
applications as a stable interface, but is easy to be understood,
debugged or even forged by humans on a console in case of need.

On 12 June 2013 09:03, Gunnar Morling <[hidden email]> 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 <[hidden email]>
>
>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] [hibernate-dev] JSON version of Hibernate Search query

Emmanuel Bernard
In reply to this post by Gunnar Morling
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 <[hidden email]>
>
> > 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
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] [hibernate-dev] JSON version of Hibernate Search query

Gunnar Morling
Would creating a "real" query language instead of a serialized object representation make sense then?

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.

For other applications (at least Java ones) which are creating queries programmatically it could also be an option to extend the DSL to allow for specifying the output format:

    String query = buildQueryBuilder()
        .forEntity( Hypothesis.class )
        .get()
        .all()
        .createQuery( Format.JSON );

    //submit query...

The DSL implementation would create an actual Lucene query, a JSON string etc., depending on the given format.

Not sure what makes sense, just throwing out some ideas.

--Gunnar




2013/6/12 Emmanuel Bernard <[hidden email]>
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 <[hidden email]>
>
> > 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
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] [hibernate-dev] [hsearch] JSON version of Hibernate Search query

Hardy Ferentschik

On 13 Jan 2013, at 8:47 AM, Gunnar Morling <[hidden email]> 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/queryparsersyntax.html ;-)
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
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] [hibernate-dev] [hsearch] JSON version of Hibernate Search query

Gunnar Morling
2013/6/13 Hardy Ferentschik <[hidden email]>

On 13 Jan 2013, at 8:47 AM, Gunnar Morling <[hidden email]> 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/queryparsersyntax.html ;-)
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.
 
> 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


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev