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 Wed, 23 Jun 2010 08:05:41 GMT
Oops this is probably i didn't checkout the modules file from the trunk.
doing that right now :)

Regards
Raakhi

On Wed, Jun 23, 2010 at 1:12 PM, Rakhi Khatwani <rkhatwani@gmail.com> wrote:

> Hi,
>        Patching did work. but when i build the trunk, i get the following
> exception:
>
> [SolrTrunk]# ant compile
> Buildfile: /testWorkspace/SolrTrunk/build.xml
>
> init-forrest-entities:
>   [mkdir] Created dir: /testWorkspace/SolrTrunk/build
>   [mkdir] Created dir: /testWorkspace/SolrTrunk/build/web
>
> compile-lucene:
>
> BUILD FAILED
> /testWorkspace/SolrTrunk/common-build.xml:207:
> /testWorkspace/modules/analysis/common does not exist.
>
> Regards,
> Raakhi
>
> On Wed, Jun 23, 2010 at 2:39 AM, Martijn v Groningen <
> martijn.is.hier@gmail.com> wrote:
>
>> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message