lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martijn v Groningen <martijn.is.h...@gmail.com>
Subject Re: Field Collapsing SOLR-236
Date Tue, 22 Jun 2010 21:09:46 GMT
What exactly did not work? Patching, compiling or running it?

On 22 June 2010 16:06, Rakhi Khatwani <rkhatwani@gmail.com> wrote:
> Hi,
>      I tried checking out the latest code (rev 956715) the patch did not
> work on it.
> Infact i even tried hunting for the revision mentioned earlier in this
> thread (i.e. rev 955615) but cannot find it in the repository. (it has
> revision 955569 followed by revision 955785).
>
> Any pointers??
> Regards
> Raakhi
>
> On Tue, Jun 22, 2010 at 2:03 AM, Martijn v Groningen <
> martijn.is.hier@gmail.com> wrote:
>
>> Oh in that case is the code stable enough to use it for production?
>>     -  Well this feature is a patch and I think that says it all.
>> Although bugs are fixed it is deferentially an experimental feature
>> and people should keep that in mind when using one of the patches.
>> Does it support features which solr 1.4 normally supports?
>>    - As far as I know yes.
>>
>> 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??
>>    - Maybee http://wiki.apache.org/solr/Deduplication prevents from
>> adding duplicates in you index, but then you miss the collapse counts
>> and other computed values
>>
>> On 21 June 2010 09:04, Rakhi Khatwani <rkhatwani@gmail.com> wrote:
>> > 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
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >
>>
>>
>>
>> --
>> Met vriendelijke groet,
>>
>> Martijn van Groningen
>>
>



-- 
Met vriendelijke groet,

Martijn van Groningen

Mime
View raw message