lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rakhi Khatwani <rkhatw...@gmail.com>
Subject Re: Field Collapsing SOLR-236
Date Mon, 21 Jun 2010 07:04:01 GMT
Hi,
    Oh in that case is the code stable enough to use it for production?
Does it support features which solr 1.4 normally supports?

I am using facets as a workaround but then i am not able to sort on any
other field. is there any workaround to support this feature??

Regards,
Raakhi

On Fri, Jun 18, 2010 at 6:14 PM, Martijn v Groningen <
martijn.is.hier@gmail.com> wrote:

> Hi Rakhi,
>
> The patch is not compatible with 1.4. If you want to work with the
> trunk. I'll need to get the src from
> https://svn.apache.org/repos/asf/lucene/dev/trunk/
>
> Martijn
>
> On 18 June 2010 13:46, Rakhi Khatwani <rkhatwani@gmail.com> wrote:
> > Hi Moazzam,
> >
> >                  Where did u get the src code from??
> >
> > I am downloading it from
> > https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4
> >
> > and the latest revision in this location is 955469.
> >
> > so applying the latest patch(dated 17th june 2010) on it still generates
> > errors.
> >
> > Any Pointers?
> >
> > Regards,
> > Raakhi
> >
> >
> > On Fri, Jun 18, 2010 at 1:24 AM, Moazzam Khan <moazzamk@gmail.com>
> wrote:
> >
> >> I knew it wasn't me! :)
> >>
> >> I found the patch just before I read this and applied it to the trunk
> >> and it works!
> >>
> >> Thanks Mark and martijn for all your help!
> >>
> >> - Moazzam
> >>
> >> On Thu, Jun 17, 2010 at 2:16 PM, Martijn v Groningen
> >> <martijn.is.hier@gmail.com> wrote:
> >> > I've added a new patch to the issue, so building the trunk (rev
> >> > 955615) with the latest patch should not be a problem. Due to recent
> >> > changes in the Lucene trunk the patch was not compatible.
> >> >
> >> > On 17 June 2010 20:20, Erik Hatcher <erik.hatcher@gmail.com> wrote:
> >> >>
> >> >> On Jun 16, 2010, at 7:31 PM, Mark Diggory wrote:
> >> >>>
> >> >>> p.s. I'd be glad to contribute our Maven build re-organization
back
> to
> >> the
> >> >>> community to get Solr properly Mavenized so that it can be
> distributed
> >> and
> >> >>> released more often.  For us the benefit of this structure is that
> we
> >> will
> >> >>> be able to overlay addons such as RequestHandlers and other third
> party
> >> >>> support without having to rebuild Solr from scratch.
> >> >>
> >> >> But you don't have to rebuild Solr from scratch to add a new request
> >> handler
> >> >> or other plugins - simply compile your custom stuff into a JAR and
> put
> >> it in
> >> >> <solr-home>/lib (or point to it with <lib> in solrconfig.xml).
> >> >>
> >> >>>  Ideally, a Maven Archetype could be created that would allow one
> >> rapidly
> >> >>> produce a Solr webapp and fire it up in Jetty in mere seconds.
> >> >>
> >> >> How's that any different than cd example; java -jar start.jar?  Or
do
> >> you
> >> >> mean a Solr client webapp?
> >> >>
> >> >>> Finally, with projects such as Bobo, integration with Spring would
> make
> >> >>> configuration more consistent and request significantly less java
> >> coding
> >> >>> just to add new capabilities everytime someone authors a new
> >> RequestHandler.
> >> >>
> >> >> It's one line of config to add a new request handler.  How many
> >> ridiculously
> >> >> ugly confusing lines of Spring XML would it take?
> >> >>
> >> >>>  The biggest thing I learned about Solr in my work thusfar is that
> >> patches
> >> >>> like these could be standalone modules in separate projects if
it
> >> weren't
> >> >>> for having to hack the configuration and solrj methods up to adopt
> >> them.
> >> >>>  Which brings me to SolrJ, great API if it would stay generic and
> have
> >> less
> >> >>> concern for adding method each time some custom collections and
> query
> >> >>> support for morelikethis or collapseddocs needs to be added.
> >> >>
> >> >> I personally find it silly that we customize SolrJ for all these
> request
> >> >> handlers anyway.  You get a decent navigable data structure back from
> >> >> general SolrJ query requests as it is, there's no need to build in
> all
> >> these
> >> >> convenience methods specific to all the Solr componetry.  Sure, it's
> >> >> "convenient", but it's a maintenance headache and as you say, not
> >> generic.
> >> >>
> >> >> But hacking configuration is reasonable, I think, for adding in
> plugins.
> >>  I
> >> >> guess you're aiming for some kind of Spring-like auto-discovery of
> >> plugins?
> >> >>  Yeah, maybe, but I'm pretty -1 on Spring coming into Solr.  It's
> >> overkill
> >> >> and ugly, IMO.  But you like it :)  And that's cool by me, to each
> their
> >> >> own.
> >> >>
> >> >> Oh, and Hi Mark! :)
> >> >>
> >> >>        Erik
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Met vriendelijke groet,
> >> >
> >> > Martijn van Groningen
> >> >
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message