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

[Michael Neale]

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 at gmail.com> 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 at jboss.org>:
>> 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 at gmail.com
>> Date: 25 September 2009 16:00:53 BST
>> To: Navin Surtani <nsurtani at redhat.com>
>> 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 at redhat.com> 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 at 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



-- 
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com