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 <gun...@hibernate.org> 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 <emman...@hibernate.org> > >> 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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
