Re: [infinispan-dev] [hibernate-dev] [HSearch] DSL for Lucene queries (was: Re: Query module new

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

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