Lexers are parsers are not difficult (a simple ANTLR grammar takes very little effort, for example), but that is orthoginal to this discussion. I believe the very term DSL is misleading (since DSL implies a separate grammar), but this is more for an intuitive builder API for query creation. And yes, while this does imply knowledge of the API, it is certainly far less verbose and more expressive than the existing query construction mechanism.

Next version of Lucene will provide helpers and tools to make it easy to create your own QueryParser, so that everyone can make his one based on business-specific needs (Everybody can already, but is not as easy). So I would avoid reinventing that, and focus on a good API. To make this API very cool IMHO it should integrate with Hibernate Search to exploit all knowledge about object mapping, declarative Analyzer and Filter definitions, and so on... We concluded in another thread that to make best use of this information we need to give the type of what you're searching for as a parameter, so that from the specific mapping the analyzers, fields and fieldbridges can be matched. Should be fine, it means we can provide typesafe results? 2009/9/27 Manik Surtani <manik(a)jboss.org&gt;: > Lexers are parsers are not difficult (a simple ANTLR grammar takes very > little effort, for example), but that is orthoginal to this discussion.  I > believe the very term DSL is misleading (since DSL implies a separate > grammar), but this is more for an intuitive builder API for query creation. >  And yes, while this does imply knowledge of the API, it is certainly far > less verbose and more expressive than the existing query construction > mechanism. > Perhaps as a next step, a grammar can be built on top of this. > - Manik > > On 25 Sep 2009, at 18:41, Navin Surtani wrote: > > Incase this email didn't go to the full dev-list. I got it as a separate > thread so forwarding on. > > Begin forwarded message: > > From: johng.sst(a)gmail.com > Date: 25 September 2009 16:00:53 BST > To: Navin Surtani <nsurtani(a)redhat.com&gt; > Subject: Re: Re: [hibernate-dev] [infinispan-dev] [HSearch] DSL for Lucene > queries (was: Re: Query module new > All, > > I think Hardy's original push back came from the first pass' use of the > decorator pattern to try to come up with a DSL. That really isn't much > better than knowing the API. The alternate is to come up with a more natural > language implementation but that leads to parsers, lexers, etc... I'm not > saying it's not worth while but it may be a lot of work. > > John Griffin > > On Sep 25, 2009 8:12am, Navin Surtani <nsurtani(a)redhat.com&gt; wrote: >> Just wanted to get this topic re-started again. >> >> >> >> >> >> Essentially what I think this project/DSL/module/thingy-bob is thought >> >> to become: - >> >> >> >> A simple package where a user can build Lucene queries without having >> >> to know too much about Lucene itself. If I'm headed down the wrong >> >> thought path then just thwack me. >> >> >> >> >> >> >> >> On 26 Aug 2009, at 21:08, Hardy Ferentschik wrote: >> >> >> >> > On Wed, 2009-08-26 at 13:39 +0200, Emmanuel Bernard wrote: >> >> >> I've been thinking about a DSL to build Lucene queries in the last >> >> >> day. >> >> >> What do you think of this proposal? >> >> > >> >> > What do you really gain compared to native Lucene queries? >> >> >> >> What's gained I believe is the fact that people can build complex >> >> lucene queries easier. Currently, it's a bit clunky imo so if we >> >> provide a cleaner way to build them it can prove beneficial to any >> >> lucene user (myself included for querying on Infinispan). >> >> >> >> Any other thoughts? >> >> >> >> >> >> > If your API achieves exactly the same as what's possible with Lucene >> >> > it is just a 'useless' wrapper. >> >> > >> >> > A wrapper around native Lucene queries would make sense if it could >> >> > somehow use some of the Hibernate Search specific meta data. As an >> >> > extreme example one could generate some meta classes a la JPA2. This >> >> > way >> >> > one could ensure that you can get help with which field names are >> >> > available. >> >> > >> >> > --Hardy >> >> > >> >> > _______________________________________________ >> >> > infinispan-dev mailing list >> >> > infinispan-dev(a)lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> >> Navin Surtani >> >> >> >> Intern Infinispan >> >> Intern JBoss Cache Searchable >> >> >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > Navin Surtani > Intern Infinispan > Intern JBoss Cache Searchable > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 28 Sep 2009, at 01:59, Michael Neale wrote: > Related to this, a SQL like language (as described in JCR) could be > nice (and like manik says, not too hard to do), I have created a wiki > page for any ideas here (really its just a link to JSR-170: > > http://www.jboss.org/community/wiki/SQL-likequeryingofInfinispan Nice. We should also create a JIRA for this (dependent on ISPN-194)

> On Sun, Sep 27, 2009 at 8:26 PM, Sanne Grinovero > <sanne.grinovero(a)gmail.com&gt; wrote: >> Next version of Lucene will provide helpers and tools to make it >> easy >> to create your own QueryParser, so that everyone can make his one >> based on business-specific needs >> (Everybody can already, but is not as easy). >> So I would avoid reinventing that, and focus on a good API. >> >> To make this API very cool IMHO it should integrate with Hibernate >> Search to exploit all knowledge about object mapping, declarative >> Analyzer and Filter definitions, and so on... >> We concluded in another thread that to make best use of this >> information we need to give the type of what you're searching for >> as a >> parameter, so that from the specific >> mapping the analyzers, fields and fieldbridges can be matched. >> Should be fine, it means we can provide typesafe results? >> >> 2009/9/27 Manik Surtani <manik(a)jboss.org&gt;: >>> Lexers are parsers are not difficult (a simple ANTLR grammar takes >>> very >>> little effort, for example), but that is orthoginal to this >>> discussion. I >>> believe the very term DSL is misleading (since DSL implies a >>> separate >>> grammar), but this is more for an intuitive builder API for query >>> creation. >>> And yes, while this does imply knowledge of the API, it is >>> certainly far >>> less verbose and more expressive than the existing query >>> construction >>> mechanism. >>> Perhaps as a next step, a grammar can be built on top of this. >>> - Manik >>> >>> On 25 Sep 2009, at 18:41, Navin Surtani wrote: >>> >>> Incase this email didn't go to the full dev-list. I got it as a >>> separate >>> thread so forwarding on. >>> >>> Begin forwarded message: >>> >>> From: johng.sst(a)gmail.com >>> Date: 25 September 2009 16:00:53 BST >>> To: Navin Surtani <nsurtani(a)redhat.com&gt; >>> Subject: Re: Re: [hibernate-dev] [infinispan-dev] [HSearch] DSL >>> for Lucene >>> queries (was: Re: Query module new >>> All, >>> >>> I think Hardy's original push back came from the first pass' use >>> of the >>> decorator pattern to try to come up with a DSL. That really isn't >>> much >>> better than knowing the API. The alternate is to come up with a >>> more natural >>> language implementation but that leads to parsers, lexers, etc... >>> I'm not >>> saying it's not worth while but it may be a lot of work. >>> >>> John Griffin >>> >>> On Sep 25, 2009 8:12am, Navin Surtani <nsurtani(a)redhat.com&gt; wrote: >>>> Just wanted to get this topic re-started again. >>>> >>>> >>>> >>>> >>>> >>>> Essentially what I think this project/DSL/module/thingy-bob is >>>> thought >>>> >>>> to become: - >>>> >>>> >>>> >>>> A simple package where a user can build Lucene queries without >>>> having >>>> >>>> to know too much about Lucene itself. If I'm headed down the wrong >>>> >>>> thought path then just thwack me. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 26 Aug 2009, at 21:08, Hardy Ferentschik wrote: >>>> >>>> >>>> >>>>> On Wed, 2009-08-26 at 13:39 +0200, Emmanuel Bernard wrote: >>>> >>>>>> I've been thinking about a DSL to build Lucene queries in the >>>>>> last >>>> >>>>>> day. >>>> >>>>>> What do you think of this proposal? >>>> >>>>> >>>> >>>>> What do you really gain compared to native Lucene queries? >>>> >>>> >>>> >>>> What's gained I believe is the fact that people can build complex >>>> >>>> lucene queries easier. Currently, it's a bit clunky imo so if we >>>> >>>> provide a cleaner way to build them it can prove beneficial to any >>>> >>>> lucene user (myself included for querying on Infinispan). >>>> >>>> >>>> >>>> Any other thoughts? >>>> >>>> >>>> >>>> >>>> >>>>> If your API achieves exactly the same as what's possible with >>>>> Lucene >>>> >>>>> it is just a 'useless' wrapper. >>>> >>>>> >>>> >>>>> A wrapper around native Lucene queries would make sense if it >>>>> could >>>> >>>>> somehow use some of the Hibernate Search specific meta data. As >>>>> an >>>> >>>>> extreme example one could generate some meta classes a la JPA2. >>>>> This >>>> >>>>> way >>>> >>>>> one could ensure that you can get help with which field names are >>>> >>>>> available. >>>> >>>>> >>>> >>>>> --Hardy >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> infinispan-dev mailing list >>>> >>>>> infinispan-dev(a)lists.jboss.org >>>> >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> >>>> >>>> >>>> Navin Surtani >>>> >>>> >>>> >>>> Intern Infinispan >>>> >>>> Intern JBoss Cache Searchable >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> hibernate-dev mailing list >>>> >>>> hibernate-dev(a)lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >>> Navin Surtani >>> Intern Infinispan >>> Intern JBoss Cache Searchable >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> -- >>> Manik Surtani >>> manik(a)jboss.org >>> Lead, Infinispan >>> Lead, JBoss Cache >>> http://www.infinispan.org >>> http://www.jbosscache.org >>> >>> >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > -- > Michael D Neale > home: www.michaelneale.net > blog: michaelneale.blogspot.com > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 27 Sep 2009, at 11:26, Sanne Grinovero wrote: > Next version of Lucene will provide helpers and tools to make it easy > to create your own QueryParser, so that everyone can make his one > based on business-specific needs > (Everybody can already, but is not as easy). > So I would avoid reinventing that, and focus on a good API. > > To make this API very cool IMHO it should integrate with Hibernate > Search to exploit all knowledge about object mapping, declarative > Analyzer and Filter definitions, and so on... > We concluded in another thread that to make best use of this > information we need to give the type of what you're searching for > as a > parameter, so that from the specific > mapping the analyzers, fields and fieldbridges can be matched. > Should be fine, it means we can provide typesafe results? Are you suggesting that this is made to be specific to Hibernate Search, rather than more generic, for Lucene? As far as Infinispan is concerned I couldn't care either way since we just depend on HS.