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

[Navin Surtani]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090925/3e3ac70f/attachment.html