You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Rakhi Khatwani <rk...@gmail.com> on 2010/06/16 10:37:51 UTC
Re: Field Collapsing SOLR-236
Hi,
I wanted to try out field collapsing for a requirement. i went through
the wiki and solr-236. but there are lot of patch files. and the comments
below left me confused.
i tried applyin the patch file on 1.4.0 release but ended up with many
compile errors.
i even downloaded the latest code from the repository and applied the
patch(solr-trunk-236 dtd 16th May 2010). but ended up with build errors.
Can someone tell me which patch file to apply on which build? so that i can
get collapsing working?
Regards,
Raakhi.
On Thu, Mar 25, 2010 at 11:15 PM, Rob Z <zm...@hotmail.com> wrote:
>
> What do you mean you had to revert to Trunk 1.5. Do you mean upgrade? Which
> version were you using before hand?
>
> Can you please list the exact version of 1.5 and the patch # you used. I
> downloaded the latest nightly build and tried patching using the 2/1 patch.
> Everything went ok but I am getting 1 failing test.
>
> Would you recommend using the latest nightly 1.5 build or 1.4 for
> production use? I really need this feature so I don't think I have much of a
> choice. Can you also explain the performance implications you are seeing AND
> what configuration tweaks you've used that helped.
>
> Thanks!
>
> > From: mark.roberts@red-gate.com
> > To: solr-user@lucene.apache.org
> > Date: Thu, 25 Mar 2010 15:21:54 +0000
> > Subject: RE: Field Collapsing SOLR-236
> >
> > Yeah got it working fine - but I needed to revert to Trunk (1.5) to get
> the patch to apply.
> >
> > It does certainly have some performance implications, but tweaking
> configuration can help here.
> >
> > Overall the benefits very much outweigh the costs for us :)
> >
> > Mark.
> >
> >
> > -----Original Message-----
> > From: Dennis Gearon [mailto:gearond@sbcglobal.net]
> > Sent: 25 March 2010 00:49
> > To: solr-user@lucene.apache.org
> > Subject: Re: Field Collapsing SOLR-236
> >
> > Boy, I hope that field collapsing works! I'm planning on using it
> heavily.
> > Dennis Gearon
> >
> > Signature Warning
> > ----------------
> > EARTH has a Right To Life,
> > otherwise we all die.
> >
> > Read 'Hot, Flat, and Crowded'
> > Laugh at http://www.yert.com/film.php
> >
> >
> > --- On Wed, 3/24/10, blargy <zm...@hotmail.com> wrote:
> >
> > > From: blargy <zm...@hotmail.com>
> > > Subject: Field Collapsing SOLR-236
> > > To: solr-user@lucene.apache.org
> > > Date: Wednesday, March 24, 2010, 12:17 PM
> > >
> > > Has anyone had any luck with the field collapsing patch
> > > (SOLR-236) with Solr
> > > 1.4? I tried patching my version of 1.4 with no such luck.
> > >
> > > Thanks
> > > --
> > > View this message in context:
> http://old.nabble.com/Field-Collapsing-SOLR-236-tp28019949p28019949.html
> > > Sent from the Solr - User mailing list archive at
> > > Nabble.com.
> > >
> > >
>
> _________________________________________________________________
> Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
> http://clk.atdmt.com/GBL/go/210850552/direct/01/
>
Re: Field Collapsing SOLR-236
Posted by Mark Diggory <md...@gmail.com>.
Correct, it uses maven and just constructs the War executable, its upto you to configure the location of your solr home directory still.
svn co https://scm.dspace.org/svn/repo/modules/dspace-solr/trunk solr
cd solr
mvn package
then you can go into the webapp/target directory and get the generated war file there and/or manipulate your solr home settings prior to deploying it.
note if you just want to use it, you don't have build it, you can just get the precompiled binary from the maven central repo....
http://repo2.maven.org/maven2/org/dspace/dependencies/solr/dspace-solr-webapp/1.4.0.1/dspace-solr-webapp-1.4.0.1.war
likewise for the modified solrj
http://repo2.maven.org/maven2/org/dspace/dependencies/solr/dspace-solr-solrj/1.4.0.1/dspace-solr-solrj-1.4.0.1.jar
Cheers,
Mark
On Jun 17, 2010, at 9:50 AM, Moazzam Khan wrote:
> Hi Mark,
>
> Thanks for posting those links. I know this is probably a dumb
> question, but how do I make Solr work through your repository? I ask
> this because I don't see a build xml file and the folder structure is
> a bit different (I'm guessing I am not supposed to use ant on that :D)
>
> Thanks,
>
> Moazzam
>
>
>
>
> On Thu, Jun 17, 2010 at 4:23 AM, Rakhi Khatwani <rk...@gmail.com> wrote:
>> Hi Moazzam,
>> Yup i hv encountered the same thing.
>> Build errors after applying the patch.
>>
>> Rakhi
>>
>> On Thu, Jun 17, 2010 at 3:33 AM, Moazzam Khan <mo...@gmail.com> wrote:
>>
>>> I got the code from trunk again and now I get this error:
>>>
>>> [javac] symbol : class StringIndex
>>> [javac] location: interface org.apache.lucene.search.FieldCache
>>> [javac] private final Map<String, FieldCache.StringIndex>
>>> fieldCaches =
>>> new HashMap<String, FieldCache.StringIndex>();
>>> [javac] ^
>>> [javac]
>>> C:\svn\solr\src\java\org\apache\solr\search\SolrIndexSearcher.java:6
>>> 74: cannot find symbol
>>> [javac] symbol : class DocSetScoreCollector
>>> [javac] location: class org.apache.solr.search.SolrIndexSearcher
>>> [javac] if (query instanceof TermQuery && !(collector instanceof
>>> Doc
>>> SetScoreCollector)) {
>>> [javac]
>>> ^
>>> [javac]
>>> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\AbstractDo
>>> cumentCollapser.java:257: cannot find symbol
>>> [javac] symbol : method
>>> getStringIndex(org.apache.solr.search.SolrIndexRead
>>> er,java.lang.String)
>>> [javac] location: interface org.apache.lucene.search.FieldCache
>>> [javac] fieldValues =
>>> FieldCache.DEFAULT.getStringIndex(searcher.getRead
>>> er(), collapseField);
>>> [javac] ^
>>> [javac]
>>> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
>>> AggregateCollapseCollectorFactory.java:163: cannot find symbol
>>> [javac] symbol : class StringIndex
>>> [javac] location: interface org.apache.lucene.search.FieldCache
>>> [javac] private final Map<String, FieldCache.StringIndex>
>>> fieldCaches =
>>> new HashMap<String, FieldCache.StringIndex>();
>>> [javac]
>>> ^
>>> [javac]
>>> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
>>> AggregateCollapseCollectorFactory.java:173: cannot find symbol
>>> [javac] symbol : method
>>> getStringIndex(org.apache.solr.search.SolrIndexRead
>>> er,java.lang.String)
>>> [javac] location: interface org.apache.lucene.search.FieldCache
>>> [javac] fieldCaches.put(fieldName,
>>> FieldCache.DEFAULT.getStringInd
>>> ex(searcher.getReader(), fieldName));
>>> [javac] ^
>>> [javac]
>>> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
>>> AggregateCollapseCollectorFactory.java:183: cannot find symbol
>>> [javac] symbol : class StringIndex
>>> [javac] location: interface org.apache.lucene.search.FieldCache
>>> [javac] FieldCache.StringIndex stringIndex =
>>> fieldCaches.get(aggrega
>>> teField.getFieldName());
>>> [javac] ^
>>> [javac] Note: Some input files use or override a deprecated API.
>>> [javac] Note: Recompile with -Xlint:deprecation for details.
>>> [javac] Note: Some input files use unchecked or unsafe operations.
>>> [javac] Note: Recompile with -Xlint:unchecked for details.
>>> [javac] 10 errors
>>>
>>>
>>> I am compiling using jdk 1.5 update 22. Does that have anything to do
>>> with the errors?
>>>
>>> -Moazzam
>>>
>>> On Wed, Jun 16, 2010 at 4:34 PM, Moazzam Khan <mo...@gmail.com> wrote:
>>>> I did the same thing. And, the code compiles without the patch but
>>>> when I apply the patch I get these errors:
>>>>
>>>> [javac]
>>> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
>>>> FieldValueCountCollapseCollectorFactory.java:127: class, interface, or
>>> enum expe
>>>> cted
>>>> [javac] import java.util.HashMap;
>>>> [javac] ^
>>>> [javac]
>>> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
>>>> FieldValueCountCollapseCollectorFactory.java:128: class, interface, or
>>> enum expe
>>>> cted
>>>> [javac] import java.util.Map;
>>>> [javac] ^
>>>> [javac]
>>> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
>>>> aggregate\AggregateFunction.java:70: class, interface, or enum expected
>>>> [javac] package
>>> org.apache.solr.search.fieldcollapse.collector.aggregate;
>>>> [javac] ^
>>>> [javac]
>>> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
>>>> aggregate\AggregateFunction.java:72: class, interface, or enum expected
>>>> [javac] import org.apache.solr.search.fieldcollapse.CollapseGroup;
>>>> [javac] ^
>>>> [javac] 52 errors
>>>>
>>>>
>>>> I got the source from :
>>>>
>>>> http://svn.apache.org/repos/asf/lucene/dev/trunk
>>>>
>>>> and got the patch from :
>>>>
>>>>
>>> https://issues.apache.org/jira/secure/attachment/12440108/SOLR-236-trunk.patch
>>>>
>>>>
>>>> Any ideas what's going wrong?
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Jun 16, 2010 at 11:40 AM, Eric Caron <er...@gmail.com>
>>> wrote:
>>>>> I've had the best luck checking out the newest Solr/Lucene (so the
>>> 1.5-line)
>>>>> from SVN, then just doing "patch -p0 < SOLR-236-trunk.patch" from inside
>>> the
>>>>> trunk directory. I just did it against the newest checkout and it works
>>> fine
>>>>> still.
>>>>>
>>>>> On Wed, Jun 16, 2010 at 11:35 AM, Moazzam Khan <mo...@gmail.com>
>>> wrote:
>>>>>
>>>>>> Actually I take that back. I am just as lost as you. I wish there was
>>>>>> a tutorial on how to do this (although I get the feeling that once I
>>>>>> know how to do it I will go "ohh... I can't believe I couldn't figure
>>>>>> that out")
>>>>>>
>>>>>> - Moazzam
>>>>>>
>>>>>> On Wed, Jun 16, 2010 at 8:25 AM, Moazzam Khan <mo...@gmail.com>
>>> wrote:
>>>>>>> Hi Rakhi,
>>>>>>>
>>>>>>> You are supposed to get the code for solr 1.4 from SVN here:
>>>>>>> http:/svn.apache.org/repos/asf/lucene/solr/tags/
>>>>>>>
>>>>>>> Then apply the path to it and comppile. It should work.
>>>>>>>
>>>>>>>
>>>>>>> However, you will probably get an error at run time saying some java
>>>>>>> class is missing. I haven't been able to figure out what to do after
>>>>>>> that.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> - moazzam
>>>>>>> http://moazzam-khan.com
>>>>>>>
>>>>>>> On Wed, Jun 16, 2010 at 3:37 AM, Rakhi Khatwani <rkhatwani@gmail.com
>>>>
>>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>> I wanted to try out field collapsing for a requirement. i went
>>>>>> through
>>>>>>>> the wiki and solr-236. but there are lot of patch files. and the
>>>>>> comments
>>>>>>>> below left me confused.
>>>>>>>>
>>>>>>>> i tried applyin the patch file on 1.4.0 release but ended up with
>>> many
>>>>>>>> compile errors.
>>>>>>>> i even downloaded the latest code from the repository and applied
>>> the
>>>>>>>> patch(solr-trunk-236 dtd 16th May 2010). but ended up with build
>>> errors.
>>>>>>>>
>>>>>>>> Can someone tell me which patch file to apply on which build? so
>>> that i
>>>>>> can
>>>>>>>> get collapsing working?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Raakhi.
>>>>>>>>
>>>>>>>> On Thu, Mar 25, 2010 at 11:15 PM, Rob Z <zm...@hotmail.com>
>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> What do you mean you had to revert to Trunk 1.5. Do you mean
>>> upgrade?
>>>>>> Which
>>>>>>>>> version were you using before hand?
>>>>>>>>>
>>>>>>>>> Can you please list the exact version of 1.5 and the patch # you
>>> used.
>>>>>> I
>>>>>>>>> downloaded the latest nightly build and tried patching using the
>>> 2/1
>>>>>> patch.
>>>>>>>>> Everything went ok but I am getting 1 failing test.
>>>>>>>>>
>>>>>>>>> Would you recommend using the latest nightly 1.5 build or 1.4 for
>>>>>>>>> production use? I really need this feature so I don't think I have
>>> much
>>>>>> of a
>>>>>>>>> choice. Can you also explain the performance implications you are
>>>>>> seeing AND
>>>>>>>>> what configuration tweaks you've used that helped.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>>> From: mark.roberts@red-gate.com
>>>>>>>>>> To: solr-user@lucene.apache.org
>>>>>>>>>> Date: Thu, 25 Mar 2010 15:21:54 +0000
>>>>>>>>>> Subject: RE: Field Collapsing SOLR-236
>>>>>>>>>>
>>>>>>>>>> Yeah got it working fine - but I needed to revert to Trunk (1.5)
>>> to
>>>>>> get
>>>>>>>>> the patch to apply.
>>>>>>>>>>
>>>>>>>>>> It does certainly have some performance implications, but
>>> tweaking
>>>>>>>>> configuration can help here.
>>>>>>>>>>
>>>>>>>>>> Overall the benefits very much outweigh the costs for us :)
>>>>>>>>>>
>>>>>>>>>> Mark.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Dennis Gearon [mailto:gearond@sbcglobal.net]
>>>>>>>>>> Sent: 25 March 2010 00:49
>>>>>>>>>> To: solr-user@lucene.apache.org
>>>>>>>>>> Subject: Re: Field Collapsing SOLR-236
>>>>>>>>>>
>>>>>>>>>> Boy, I hope that field collapsing works! I'm planning on using it
>>>>>>>>> heavily.
>>>>>>>>>> Dennis Gearon
>>>>>>>>>>
>>>>>>>>>> Signature Warning
>>>>>>>>>> ----------------
>>>>>>>>>> EARTH has a Right To Life,
>>>>>>>>>> otherwise we all die.
>>>>>>>>>>
>>>>>>>>>> Read 'Hot, Flat, and Crowded'
>>>>>>>>>> Laugh at http://www.yert.com/film.php
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --- On Wed, 3/24/10, blargy <zm...@hotmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> From: blargy <zm...@hotmail.com>
>>>>>>>>>>> Subject: Field Collapsing SOLR-236
>>>>>>>>>>> To: solr-user@lucene.apache.org
>>>>>>>>>>> Date: Wednesday, March 24, 2010, 12:17 PM
>>>>>>>>>>>
>>>>>>>>>>> Has anyone had any luck with the field collapsing patch
>>>>>>>>>>> (SOLR-236) with Solr
>>>>>>>>>>> 1.4? I tried patching my version of 1.4 with no such luck.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> --
>>>>>>>>>>> View this message in context:
>>>>>>>>>
>>>>>>
>>> http://old.nabble.com/Field-Collapsing-SOLR-236-tp28019949p28019949.html
>>>>>>>>>>> Sent from the Solr - User mailing list archive at
>>>>>>>>>>> Nabble.com.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _________________________________________________________________
>>>>>>>>> Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
>>>>>>>>> http://clk.atdmt.com/GBL/go/210850552/direct/01/
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
Re: Field Collapsing SOLR-236
Posted by Moazzam Khan <mo...@gmail.com>.
Hi Mark,
Thanks for posting those links. I know this is probably a dumb
question, but how do I make Solr work through your repository? I ask
this because I don't see a build xml file and the folder structure is
a bit different (I'm guessing I am not supposed to use ant on that :D)
Thanks,
Moazzam
On Thu, Jun 17, 2010 at 4:23 AM, Rakhi Khatwani <rk...@gmail.com> wrote:
> Hi Moazzam,
> Yup i hv encountered the same thing.
> Build errors after applying the patch.
>
> Rakhi
>
> On Thu, Jun 17, 2010 at 3:33 AM, Moazzam Khan <mo...@gmail.com> wrote:
>
>> I got the code from trunk again and now I get this error:
>>
>> [javac] symbol : class StringIndex
>> [javac] location: interface org.apache.lucene.search.FieldCache
>> [javac] private final Map<String, FieldCache.StringIndex>
>> fieldCaches =
>> new HashMap<String, FieldCache.StringIndex>();
>> [javac] ^
>> [javac]
>> C:\svn\solr\src\java\org\apache\solr\search\SolrIndexSearcher.java:6
>> 74: cannot find symbol
>> [javac] symbol : class DocSetScoreCollector
>> [javac] location: class org.apache.solr.search.SolrIndexSearcher
>> [javac] if (query instanceof TermQuery && !(collector instanceof
>> Doc
>> SetScoreCollector)) {
>> [javac]
>> ^
>> [javac]
>> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\AbstractDo
>> cumentCollapser.java:257: cannot find symbol
>> [javac] symbol : method
>> getStringIndex(org.apache.solr.search.SolrIndexRead
>> er,java.lang.String)
>> [javac] location: interface org.apache.lucene.search.FieldCache
>> [javac] fieldValues =
>> FieldCache.DEFAULT.getStringIndex(searcher.getRead
>> er(), collapseField);
>> [javac] ^
>> [javac]
>> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
>> AggregateCollapseCollectorFactory.java:163: cannot find symbol
>> [javac] symbol : class StringIndex
>> [javac] location: interface org.apache.lucene.search.FieldCache
>> [javac] private final Map<String, FieldCache.StringIndex>
>> fieldCaches =
>> new HashMap<String, FieldCache.StringIndex>();
>> [javac]
>> ^
>> [javac]
>> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
>> AggregateCollapseCollectorFactory.java:173: cannot find symbol
>> [javac] symbol : method
>> getStringIndex(org.apache.solr.search.SolrIndexRead
>> er,java.lang.String)
>> [javac] location: interface org.apache.lucene.search.FieldCache
>> [javac] fieldCaches.put(fieldName,
>> FieldCache.DEFAULT.getStringInd
>> ex(searcher.getReader(), fieldName));
>> [javac] ^
>> [javac]
>> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
>> AggregateCollapseCollectorFactory.java:183: cannot find symbol
>> [javac] symbol : class StringIndex
>> [javac] location: interface org.apache.lucene.search.FieldCache
>> [javac] FieldCache.StringIndex stringIndex =
>> fieldCaches.get(aggrega
>> teField.getFieldName());
>> [javac] ^
>> [javac] Note: Some input files use or override a deprecated API.
>> [javac] Note: Recompile with -Xlint:deprecation for details.
>> [javac] Note: Some input files use unchecked or unsafe operations.
>> [javac] Note: Recompile with -Xlint:unchecked for details.
>> [javac] 10 errors
>>
>>
>> I am compiling using jdk 1.5 update 22. Does that have anything to do
>> with the errors?
>>
>> -Moazzam
>>
>> On Wed, Jun 16, 2010 at 4:34 PM, Moazzam Khan <mo...@gmail.com> wrote:
>> > I did the same thing. And, the code compiles without the patch but
>> > when I apply the patch I get these errors:
>> >
>> > [javac]
>> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
>> > FieldValueCountCollapseCollectorFactory.java:127: class, interface, or
>> enum expe
>> > cted
>> > [javac] import java.util.HashMap;
>> > [javac] ^
>> > [javac]
>> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
>> > FieldValueCountCollapseCollectorFactory.java:128: class, interface, or
>> enum expe
>> > cted
>> > [javac] import java.util.Map;
>> > [javac] ^
>> > [javac]
>> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
>> > aggregate\AggregateFunction.java:70: class, interface, or enum expected
>> > [javac] package
>> org.apache.solr.search.fieldcollapse.collector.aggregate;
>> > [javac] ^
>> > [javac]
>> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
>> > aggregate\AggregateFunction.java:72: class, interface, or enum expected
>> > [javac] import org.apache.solr.search.fieldcollapse.CollapseGroup;
>> > [javac] ^
>> > [javac] 52 errors
>> >
>> >
>> > I got the source from :
>> >
>> > http://svn.apache.org/repos/asf/lucene/dev/trunk
>> >
>> > and got the patch from :
>> >
>> >
>> https://issues.apache.org/jira/secure/attachment/12440108/SOLR-236-trunk.patch
>> >
>> >
>> > Any ideas what's going wrong?
>> >
>> >
>> >
>> >
>> > On Wed, Jun 16, 2010 at 11:40 AM, Eric Caron <er...@gmail.com>
>> wrote:
>> >> I've had the best luck checking out the newest Solr/Lucene (so the
>> 1.5-line)
>> >> from SVN, then just doing "patch -p0 < SOLR-236-trunk.patch" from inside
>> the
>> >> trunk directory. I just did it against the newest checkout and it works
>> fine
>> >> still.
>> >>
>> >> On Wed, Jun 16, 2010 at 11:35 AM, Moazzam Khan <mo...@gmail.com>
>> wrote:
>> >>
>> >>> Actually I take that back. I am just as lost as you. I wish there was
>> >>> a tutorial on how to do this (although I get the feeling that once I
>> >>> know how to do it I will go "ohh... I can't believe I couldn't figure
>> >>> that out")
>> >>>
>> >>> - Moazzam
>> >>>
>> >>> On Wed, Jun 16, 2010 at 8:25 AM, Moazzam Khan <mo...@gmail.com>
>> wrote:
>> >>> > Hi Rakhi,
>> >>> >
>> >>> > You are supposed to get the code for solr 1.4 from SVN here:
>> >>> > http:/svn.apache.org/repos/asf/lucene/solr/tags/
>> >>> >
>> >>> > Then apply the path to it and comppile. It should work.
>> >>> >
>> >>> >
>> >>> > However, you will probably get an error at run time saying some java
>> >>> > class is missing. I haven't been able to figure out what to do after
>> >>> > that.
>> >>> >
>> >>> >
>> >>> >
>> >>> > - moazzam
>> >>> > http://moazzam-khan.com
>> >>> >
>> >>> > On Wed, Jun 16, 2010 at 3:37 AM, Rakhi Khatwani <rkhatwani@gmail.com
>> >
>> >>> wrote:
>> >>> >> Hi,
>> >>> >> I wanted to try out field collapsing for a requirement. i went
>> >>> through
>> >>> >> the wiki and solr-236. but there are lot of patch files. and the
>> >>> comments
>> >>> >> below left me confused.
>> >>> >>
>> >>> >> i tried applyin the patch file on 1.4.0 release but ended up with
>> many
>> >>> >> compile errors.
>> >>> >> i even downloaded the latest code from the repository and applied
>> the
>> >>> >> patch(solr-trunk-236 dtd 16th May 2010). but ended up with build
>> errors.
>> >>> >>
>> >>> >> Can someone tell me which patch file to apply on which build? so
>> that i
>> >>> can
>> >>> >> get collapsing working?
>> >>> >>
>> >>> >> Regards,
>> >>> >> Raakhi.
>> >>> >>
>> >>> >> On Thu, Mar 25, 2010 at 11:15 PM, Rob Z <zm...@hotmail.com>
>> wrote:
>> >>> >>
>> >>> >>>
>> >>> >>> What do you mean you had to revert to Trunk 1.5. Do you mean
>> upgrade?
>> >>> Which
>> >>> >>> version were you using before hand?
>> >>> >>>
>> >>> >>> Can you please list the exact version of 1.5 and the patch # you
>> used.
>> >>> I
>> >>> >>> downloaded the latest nightly build and tried patching using the
>> 2/1
>> >>> patch.
>> >>> >>> Everything went ok but I am getting 1 failing test.
>> >>> >>>
>> >>> >>> Would you recommend using the latest nightly 1.5 build or 1.4 for
>> >>> >>> production use? I really need this feature so I don't think I have
>> much
>> >>> of a
>> >>> >>> choice. Can you also explain the performance implications you are
>> >>> seeing AND
>> >>> >>> what configuration tweaks you've used that helped.
>> >>> >>>
>> >>> >>> Thanks!
>> >>> >>>
>> >>> >>> > From: mark.roberts@red-gate.com
>> >>> >>> > To: solr-user@lucene.apache.org
>> >>> >>> > Date: Thu, 25 Mar 2010 15:21:54 +0000
>> >>> >>> > Subject: RE: Field Collapsing SOLR-236
>> >>> >>> >
>> >>> >>> > Yeah got it working fine - but I needed to revert to Trunk (1.5)
>> to
>> >>> get
>> >>> >>> the patch to apply.
>> >>> >>> >
>> >>> >>> > It does certainly have some performance implications, but
>> tweaking
>> >>> >>> configuration can help here.
>> >>> >>> >
>> >>> >>> > Overall the benefits very much outweigh the costs for us :)
>> >>> >>> >
>> >>> >>> > Mark.
>> >>> >>> >
>> >>> >>> >
>> >>> >>> > -----Original Message-----
>> >>> >>> > From: Dennis Gearon [mailto:gearond@sbcglobal.net]
>> >>> >>> > Sent: 25 March 2010 00:49
>> >>> >>> > To: solr-user@lucene.apache.org
>> >>> >>> > Subject: Re: Field Collapsing SOLR-236
>> >>> >>> >
>> >>> >>> > Boy, I hope that field collapsing works! I'm planning on using it
>> >>> >>> heavily.
>> >>> >>> > Dennis Gearon
>> >>> >>> >
>> >>> >>> > Signature Warning
>> >>> >>> > ----------------
>> >>> >>> > EARTH has a Right To Life,
>> >>> >>> > otherwise we all die.
>> >>> >>> >
>> >>> >>> > Read 'Hot, Flat, and Crowded'
>> >>> >>> > Laugh at http://www.yert.com/film.php
>> >>> >>> >
>> >>> >>> >
>> >>> >>> > --- On Wed, 3/24/10, blargy <zm...@hotmail.com> wrote:
>> >>> >>> >
>> >>> >>> > > From: blargy <zm...@hotmail.com>
>> >>> >>> > > Subject: Field Collapsing SOLR-236
>> >>> >>> > > To: solr-user@lucene.apache.org
>> >>> >>> > > Date: Wednesday, March 24, 2010, 12:17 PM
>> >>> >>> > >
>> >>> >>> > > Has anyone had any luck with the field collapsing patch
>> >>> >>> > > (SOLR-236) with Solr
>> >>> >>> > > 1.4? I tried patching my version of 1.4 with no such luck.
>> >>> >>> > >
>> >>> >>> > > Thanks
>> >>> >>> > > --
>> >>> >>> > > View this message in context:
>> >>> >>>
>> >>>
>> http://old.nabble.com/Field-Collapsing-SOLR-236-tp28019949p28019949.html
>> >>> >>> > > Sent from the Solr - User mailing list archive at
>> >>> >>> > > Nabble.com.
>> >>> >>> > >
>> >>> >>> > >
>> >>> >>>
>> >>> >>> _________________________________________________________________
>> >>> >>> Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
>> >>> >>> http://clk.atdmt.com/GBL/go/210850552/direct/01/
>> >>> >>>
>> >>> >>
>> >>> >
>> >>>
>> >>
>> >
>>
>
Re: Field Collapsing SOLR-236
Posted by Rakhi Khatwani <rk...@gmail.com>.
Hi Moazzam,
Yup i hv encountered the same thing.
Build errors after applying the patch.
Rakhi
On Thu, Jun 17, 2010 at 3:33 AM, Moazzam Khan <mo...@gmail.com> wrote:
> I got the code from trunk again and now I get this error:
>
> [javac] symbol : class StringIndex
> [javac] location: interface org.apache.lucene.search.FieldCache
> [javac] private final Map<String, FieldCache.StringIndex>
> fieldCaches =
> new HashMap<String, FieldCache.StringIndex>();
> [javac] ^
> [javac]
> C:\svn\solr\src\java\org\apache\solr\search\SolrIndexSearcher.java:6
> 74: cannot find symbol
> [javac] symbol : class DocSetScoreCollector
> [javac] location: class org.apache.solr.search.SolrIndexSearcher
> [javac] if (query instanceof TermQuery && !(collector instanceof
> Doc
> SetScoreCollector)) {
> [javac]
> ^
> [javac]
> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\AbstractDo
> cumentCollapser.java:257: cannot find symbol
> [javac] symbol : method
> getStringIndex(org.apache.solr.search.SolrIndexRead
> er,java.lang.String)
> [javac] location: interface org.apache.lucene.search.FieldCache
> [javac] fieldValues =
> FieldCache.DEFAULT.getStringIndex(searcher.getRead
> er(), collapseField);
> [javac] ^
> [javac]
> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
> AggregateCollapseCollectorFactory.java:163: cannot find symbol
> [javac] symbol : class StringIndex
> [javac] location: interface org.apache.lucene.search.FieldCache
> [javac] private final Map<String, FieldCache.StringIndex>
> fieldCaches =
> new HashMap<String, FieldCache.StringIndex>();
> [javac]
> ^
> [javac]
> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
> AggregateCollapseCollectorFactory.java:173: cannot find symbol
> [javac] symbol : method
> getStringIndex(org.apache.solr.search.SolrIndexRead
> er,java.lang.String)
> [javac] location: interface org.apache.lucene.search.FieldCache
> [javac] fieldCaches.put(fieldName,
> FieldCache.DEFAULT.getStringInd
> ex(searcher.getReader(), fieldName));
> [javac] ^
> [javac]
> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
> AggregateCollapseCollectorFactory.java:183: cannot find symbol
> [javac] symbol : class StringIndex
> [javac] location: interface org.apache.lucene.search.FieldCache
> [javac] FieldCache.StringIndex stringIndex =
> fieldCaches.get(aggrega
> teField.getFieldName());
> [javac] ^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
> [javac] Note: Some input files use unchecked or unsafe operations.
> [javac] Note: Recompile with -Xlint:unchecked for details.
> [javac] 10 errors
>
>
> I am compiling using jdk 1.5 update 22. Does that have anything to do
> with the errors?
>
> -Moazzam
>
> On Wed, Jun 16, 2010 at 4:34 PM, Moazzam Khan <mo...@gmail.com> wrote:
> > I did the same thing. And, the code compiles without the patch but
> > when I apply the patch I get these errors:
> >
> > [javac]
> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
> > FieldValueCountCollapseCollectorFactory.java:127: class, interface, or
> enum expe
> > cted
> > [javac] import java.util.HashMap;
> > [javac] ^
> > [javac]
> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
> > FieldValueCountCollapseCollectorFactory.java:128: class, interface, or
> enum expe
> > cted
> > [javac] import java.util.Map;
> > [javac] ^
> > [javac]
> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
> > aggregate\AggregateFunction.java:70: class, interface, or enum expected
> > [javac] package
> org.apache.solr.search.fieldcollapse.collector.aggregate;
> > [javac] ^
> > [javac]
> C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
> > aggregate\AggregateFunction.java:72: class, interface, or enum expected
> > [javac] import org.apache.solr.search.fieldcollapse.CollapseGroup;
> > [javac] ^
> > [javac] 52 errors
> >
> >
> > I got the source from :
> >
> > http://svn.apache.org/repos/asf/lucene/dev/trunk
> >
> > and got the patch from :
> >
> >
> https://issues.apache.org/jira/secure/attachment/12440108/SOLR-236-trunk.patch
> >
> >
> > Any ideas what's going wrong?
> >
> >
> >
> >
> > On Wed, Jun 16, 2010 at 11:40 AM, Eric Caron <er...@gmail.com>
> wrote:
> >> I've had the best luck checking out the newest Solr/Lucene (so the
> 1.5-line)
> >> from SVN, then just doing "patch -p0 < SOLR-236-trunk.patch" from inside
> the
> >> trunk directory. I just did it against the newest checkout and it works
> fine
> >> still.
> >>
> >> On Wed, Jun 16, 2010 at 11:35 AM, Moazzam Khan <mo...@gmail.com>
> wrote:
> >>
> >>> Actually I take that back. I am just as lost as you. I wish there was
> >>> a tutorial on how to do this (although I get the feeling that once I
> >>> know how to do it I will go "ohh... I can't believe I couldn't figure
> >>> that out")
> >>>
> >>> - Moazzam
> >>>
> >>> On Wed, Jun 16, 2010 at 8:25 AM, Moazzam Khan <mo...@gmail.com>
> wrote:
> >>> > Hi Rakhi,
> >>> >
> >>> > You are supposed to get the code for solr 1.4 from SVN here:
> >>> > http:/svn.apache.org/repos/asf/lucene/solr/tags/
> >>> >
> >>> > Then apply the path to it and comppile. It should work.
> >>> >
> >>> >
> >>> > However, you will probably get an error at run time saying some java
> >>> > class is missing. I haven't been able to figure out what to do after
> >>> > that.
> >>> >
> >>> >
> >>> >
> >>> > - moazzam
> >>> > http://moazzam-khan.com
> >>> >
> >>> > On Wed, Jun 16, 2010 at 3:37 AM, Rakhi Khatwani <rkhatwani@gmail.com
> >
> >>> wrote:
> >>> >> Hi,
> >>> >> I wanted to try out field collapsing for a requirement. i went
> >>> through
> >>> >> the wiki and solr-236. but there are lot of patch files. and the
> >>> comments
> >>> >> below left me confused.
> >>> >>
> >>> >> i tried applyin the patch file on 1.4.0 release but ended up with
> many
> >>> >> compile errors.
> >>> >> i even downloaded the latest code from the repository and applied
> the
> >>> >> patch(solr-trunk-236 dtd 16th May 2010). but ended up with build
> errors.
> >>> >>
> >>> >> Can someone tell me which patch file to apply on which build? so
> that i
> >>> can
> >>> >> get collapsing working?
> >>> >>
> >>> >> Regards,
> >>> >> Raakhi.
> >>> >>
> >>> >> On Thu, Mar 25, 2010 at 11:15 PM, Rob Z <zm...@hotmail.com>
> wrote:
> >>> >>
> >>> >>>
> >>> >>> What do you mean you had to revert to Trunk 1.5. Do you mean
> upgrade?
> >>> Which
> >>> >>> version were you using before hand?
> >>> >>>
> >>> >>> Can you please list the exact version of 1.5 and the patch # you
> used.
> >>> I
> >>> >>> downloaded the latest nightly build and tried patching using the
> 2/1
> >>> patch.
> >>> >>> Everything went ok but I am getting 1 failing test.
> >>> >>>
> >>> >>> Would you recommend using the latest nightly 1.5 build or 1.4 for
> >>> >>> production use? I really need this feature so I don't think I have
> much
> >>> of a
> >>> >>> choice. Can you also explain the performance implications you are
> >>> seeing AND
> >>> >>> what configuration tweaks you've used that helped.
> >>> >>>
> >>> >>> Thanks!
> >>> >>>
> >>> >>> > From: mark.roberts@red-gate.com
> >>> >>> > To: solr-user@lucene.apache.org
> >>> >>> > Date: Thu, 25 Mar 2010 15:21:54 +0000
> >>> >>> > Subject: RE: Field Collapsing SOLR-236
> >>> >>> >
> >>> >>> > Yeah got it working fine - but I needed to revert to Trunk (1.5)
> to
> >>> get
> >>> >>> the patch to apply.
> >>> >>> >
> >>> >>> > It does certainly have some performance implications, but
> tweaking
> >>> >>> configuration can help here.
> >>> >>> >
> >>> >>> > Overall the benefits very much outweigh the costs for us :)
> >>> >>> >
> >>> >>> > Mark.
> >>> >>> >
> >>> >>> >
> >>> >>> > -----Original Message-----
> >>> >>> > From: Dennis Gearon [mailto:gearond@sbcglobal.net]
> >>> >>> > Sent: 25 March 2010 00:49
> >>> >>> > To: solr-user@lucene.apache.org
> >>> >>> > Subject: Re: Field Collapsing SOLR-236
> >>> >>> >
> >>> >>> > Boy, I hope that field collapsing works! I'm planning on using it
> >>> >>> heavily.
> >>> >>> > Dennis Gearon
> >>> >>> >
> >>> >>> > Signature Warning
> >>> >>> > ----------------
> >>> >>> > EARTH has a Right To Life,
> >>> >>> > otherwise we all die.
> >>> >>> >
> >>> >>> > Read 'Hot, Flat, and Crowded'
> >>> >>> > Laugh at http://www.yert.com/film.php
> >>> >>> >
> >>> >>> >
> >>> >>> > --- On Wed, 3/24/10, blargy <zm...@hotmail.com> wrote:
> >>> >>> >
> >>> >>> > > From: blargy <zm...@hotmail.com>
> >>> >>> > > Subject: Field Collapsing SOLR-236
> >>> >>> > > To: solr-user@lucene.apache.org
> >>> >>> > > Date: Wednesday, March 24, 2010, 12:17 PM
> >>> >>> > >
> >>> >>> > > Has anyone had any luck with the field collapsing patch
> >>> >>> > > (SOLR-236) with Solr
> >>> >>> > > 1.4? I tried patching my version of 1.4 with no such luck.
> >>> >>> > >
> >>> >>> > > Thanks
> >>> >>> > > --
> >>> >>> > > View this message in context:
> >>> >>>
> >>>
> http://old.nabble.com/Field-Collapsing-SOLR-236-tp28019949p28019949.html
> >>> >>> > > Sent from the Solr - User mailing list archive at
> >>> >>> > > Nabble.com.
> >>> >>> > >
> >>> >>> > >
> >>> >>>
> >>> >>> _________________________________________________________________
> >>> >>> Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
> >>> >>> http://clk.atdmt.com/GBL/go/210850552/direct/01/
> >>> >>>
> >>> >>
> >>> >
> >>>
> >>
> >
>
Re: Field Collapsing SOLR-236
Posted by Moazzam Khan <mo...@gmail.com>.
I got the code from trunk again and now I get this error:
[javac] symbol : class StringIndex
[javac] location: interface org.apache.lucene.search.FieldCache
[javac] private final Map<String, FieldCache.StringIndex> fieldCaches =
new HashMap<String, FieldCache.StringIndex>();
[javac] ^
[javac] C:\svn\solr\src\java\org\apache\solr\search\SolrIndexSearcher.java:6
74: cannot find symbol
[javac] symbol : class DocSetScoreCollector
[javac] location: class org.apache.solr.search.SolrIndexSearcher
[javac] if (query instanceof TermQuery && !(collector instanceof Doc
SetScoreCollector)) {
[javac] ^
[javac] C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\AbstractDo
cumentCollapser.java:257: cannot find symbol
[javac] symbol : method getStringIndex(org.apache.solr.search.SolrIndexRead
er,java.lang.String)
[javac] location: interface org.apache.lucene.search.FieldCache
[javac] fieldValues = FieldCache.DEFAULT.getStringIndex(searcher.getRead
er(), collapseField);
[javac] ^
[javac] C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
AggregateCollapseCollectorFactory.java:163: cannot find symbol
[javac] symbol : class StringIndex
[javac] location: interface org.apache.lucene.search.FieldCache
[javac] private final Map<String, FieldCache.StringIndex> fieldCaches =
new HashMap<String, FieldCache.StringIndex>();
[javac]
^
[javac] C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
AggregateCollapseCollectorFactory.java:173: cannot find symbol
[javac] symbol : method getStringIndex(org.apache.solr.search.SolrIndexRead
er,java.lang.String)
[javac] location: interface org.apache.lucene.search.FieldCache
[javac] fieldCaches.put(fieldName, FieldCache.DEFAULT.getStringInd
ex(searcher.getReader(), fieldName));
[javac] ^
[javac] C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
AggregateCollapseCollectorFactory.java:183: cannot find symbol
[javac] symbol : class StringIndex
[javac] location: interface org.apache.lucene.search.FieldCache
[javac] FieldCache.StringIndex stringIndex = fieldCaches.get(aggrega
teField.getFieldName());
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 10 errors
I am compiling using jdk 1.5 update 22. Does that have anything to do
with the errors?
-Moazzam
On Wed, Jun 16, 2010 at 4:34 PM, Moazzam Khan <mo...@gmail.com> wrote:
> I did the same thing. And, the code compiles without the patch but
> when I apply the patch I get these errors:
>
> [javac] C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
> FieldValueCountCollapseCollectorFactory.java:127: class, interface, or enum expe
> cted
> [javac] import java.util.HashMap;
> [javac] ^
> [javac] C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
> FieldValueCountCollapseCollectorFactory.java:128: class, interface, or enum expe
> cted
> [javac] import java.util.Map;
> [javac] ^
> [javac] C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
> aggregate\AggregateFunction.java:70: class, interface, or enum expected
> [javac] package org.apache.solr.search.fieldcollapse.collector.aggregate;
> [javac] ^
> [javac] C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
> aggregate\AggregateFunction.java:72: class, interface, or enum expected
> [javac] import org.apache.solr.search.fieldcollapse.CollapseGroup;
> [javac] ^
> [javac] 52 errors
>
>
> I got the source from :
>
> http://svn.apache.org/repos/asf/lucene/dev/trunk
>
> and got the patch from :
>
> https://issues.apache.org/jira/secure/attachment/12440108/SOLR-236-trunk.patch
>
>
> Any ideas what's going wrong?
>
>
>
>
> On Wed, Jun 16, 2010 at 11:40 AM, Eric Caron <er...@gmail.com> wrote:
>> I've had the best luck checking out the newest Solr/Lucene (so the 1.5-line)
>> from SVN, then just doing "patch -p0 < SOLR-236-trunk.patch" from inside the
>> trunk directory. I just did it against the newest checkout and it works fine
>> still.
>>
>> On Wed, Jun 16, 2010 at 11:35 AM, Moazzam Khan <mo...@gmail.com> wrote:
>>
>>> Actually I take that back. I am just as lost as you. I wish there was
>>> a tutorial on how to do this (although I get the feeling that once I
>>> know how to do it I will go "ohh... I can't believe I couldn't figure
>>> that out")
>>>
>>> - Moazzam
>>>
>>> On Wed, Jun 16, 2010 at 8:25 AM, Moazzam Khan <mo...@gmail.com> wrote:
>>> > Hi Rakhi,
>>> >
>>> > You are supposed to get the code for solr 1.4 from SVN here:
>>> > http:/svn.apache.org/repos/asf/lucene/solr/tags/
>>> >
>>> > Then apply the path to it and comppile. It should work.
>>> >
>>> >
>>> > However, you will probably get an error at run time saying some java
>>> > class is missing. I haven't been able to figure out what to do after
>>> > that.
>>> >
>>> >
>>> >
>>> > - moazzam
>>> > http://moazzam-khan.com
>>> >
>>> > On Wed, Jun 16, 2010 at 3:37 AM, Rakhi Khatwani <rk...@gmail.com>
>>> wrote:
>>> >> Hi,
>>> >> I wanted to try out field collapsing for a requirement. i went
>>> through
>>> >> the wiki and solr-236. but there are lot of patch files. and the
>>> comments
>>> >> below left me confused.
>>> >>
>>> >> i tried applyin the patch file on 1.4.0 release but ended up with many
>>> >> compile errors.
>>> >> i even downloaded the latest code from the repository and applied the
>>> >> patch(solr-trunk-236 dtd 16th May 2010). but ended up with build errors.
>>> >>
>>> >> Can someone tell me which patch file to apply on which build? so that i
>>> can
>>> >> get collapsing working?
>>> >>
>>> >> Regards,
>>> >> Raakhi.
>>> >>
>>> >> On Thu, Mar 25, 2010 at 11:15 PM, Rob Z <zm...@hotmail.com> wrote:
>>> >>
>>> >>>
>>> >>> What do you mean you had to revert to Trunk 1.5. Do you mean upgrade?
>>> Which
>>> >>> version were you using before hand?
>>> >>>
>>> >>> Can you please list the exact version of 1.5 and the patch # you used.
>>> I
>>> >>> downloaded the latest nightly build and tried patching using the 2/1
>>> patch.
>>> >>> Everything went ok but I am getting 1 failing test.
>>> >>>
>>> >>> Would you recommend using the latest nightly 1.5 build or 1.4 for
>>> >>> production use? I really need this feature so I don't think I have much
>>> of a
>>> >>> choice. Can you also explain the performance implications you are
>>> seeing AND
>>> >>> what configuration tweaks you've used that helped.
>>> >>>
>>> >>> Thanks!
>>> >>>
>>> >>> > From: mark.roberts@red-gate.com
>>> >>> > To: solr-user@lucene.apache.org
>>> >>> > Date: Thu, 25 Mar 2010 15:21:54 +0000
>>> >>> > Subject: RE: Field Collapsing SOLR-236
>>> >>> >
>>> >>> > Yeah got it working fine - but I needed to revert to Trunk (1.5) to
>>> get
>>> >>> the patch to apply.
>>> >>> >
>>> >>> > It does certainly have some performance implications, but tweaking
>>> >>> configuration can help here.
>>> >>> >
>>> >>> > Overall the benefits very much outweigh the costs for us :)
>>> >>> >
>>> >>> > Mark.
>>> >>> >
>>> >>> >
>>> >>> > -----Original Message-----
>>> >>> > From: Dennis Gearon [mailto:gearond@sbcglobal.net]
>>> >>> > Sent: 25 March 2010 00:49
>>> >>> > To: solr-user@lucene.apache.org
>>> >>> > Subject: Re: Field Collapsing SOLR-236
>>> >>> >
>>> >>> > Boy, I hope that field collapsing works! I'm planning on using it
>>> >>> heavily.
>>> >>> > Dennis Gearon
>>> >>> >
>>> >>> > Signature Warning
>>> >>> > ----------------
>>> >>> > EARTH has a Right To Life,
>>> >>> > otherwise we all die.
>>> >>> >
>>> >>> > Read 'Hot, Flat, and Crowded'
>>> >>> > Laugh at http://www.yert.com/film.php
>>> >>> >
>>> >>> >
>>> >>> > --- On Wed, 3/24/10, blargy <zm...@hotmail.com> wrote:
>>> >>> >
>>> >>> > > From: blargy <zm...@hotmail.com>
>>> >>> > > Subject: Field Collapsing SOLR-236
>>> >>> > > To: solr-user@lucene.apache.org
>>> >>> > > Date: Wednesday, March 24, 2010, 12:17 PM
>>> >>> > >
>>> >>> > > Has anyone had any luck with the field collapsing patch
>>> >>> > > (SOLR-236) with Solr
>>> >>> > > 1.4? I tried patching my version of 1.4 with no such luck.
>>> >>> > >
>>> >>> > > Thanks
>>> >>> > > --
>>> >>> > > View this message in context:
>>> >>>
>>> http://old.nabble.com/Field-Collapsing-SOLR-236-tp28019949p28019949.html
>>> >>> > > Sent from the Solr - User mailing list archive at
>>> >>> > > Nabble.com.
>>> >>> > >
>>> >>> > >
>>> >>>
>>> >>> _________________________________________________________________
>>> >>> Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
>>> >>> http://clk.atdmt.com/GBL/go/210850552/direct/01/
>>> >>>
>>> >>
>>> >
>>>
>>
>
Re: Field Collapsing SOLR-236
Posted by Moazzam Khan <mo...@gmail.com>.
I did the same thing. And, the code compiles without the patch but
when I apply the patch I get these errors:
[javac] C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
FieldValueCountCollapseCollectorFactory.java:127: class, interface, or enum expe
cted
[javac] import java.util.HashMap;
[javac] ^
[javac] C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
FieldValueCountCollapseCollectorFactory.java:128: class, interface, or enum expe
cted
[javac] import java.util.Map;
[javac] ^
[javac] C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
aggregate\AggregateFunction.java:70: class, interface, or enum expected
[javac] package org.apache.solr.search.fieldcollapse.collector.aggregate;
[javac] ^
[javac] C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
aggregate\AggregateFunction.java:72: class, interface, or enum expected
[javac] import org.apache.solr.search.fieldcollapse.CollapseGroup;
[javac] ^
[javac] 52 errors
I got the source from :
http://svn.apache.org/repos/asf/lucene/dev/trunk
and got the patch from :
https://issues.apache.org/jira/secure/attachment/12440108/SOLR-236-trunk.patch
Any ideas what's going wrong?
On Wed, Jun 16, 2010 at 11:40 AM, Eric Caron <er...@gmail.com> wrote:
> I've had the best luck checking out the newest Solr/Lucene (so the 1.5-line)
> from SVN, then just doing "patch -p0 < SOLR-236-trunk.patch" from inside the
> trunk directory. I just did it against the newest checkout and it works fine
> still.
>
> On Wed, Jun 16, 2010 at 11:35 AM, Moazzam Khan <mo...@gmail.com> wrote:
>
>> Actually I take that back. I am just as lost as you. I wish there was
>> a tutorial on how to do this (although I get the feeling that once I
>> know how to do it I will go "ohh... I can't believe I couldn't figure
>> that out")
>>
>> - Moazzam
>>
>> On Wed, Jun 16, 2010 at 8:25 AM, Moazzam Khan <mo...@gmail.com> wrote:
>> > Hi Rakhi,
>> >
>> > You are supposed to get the code for solr 1.4 from SVN here:
>> > http:/svn.apache.org/repos/asf/lucene/solr/tags/
>> >
>> > Then apply the path to it and comppile. It should work.
>> >
>> >
>> > However, you will probably get an error at run time saying some java
>> > class is missing. I haven't been able to figure out what to do after
>> > that.
>> >
>> >
>> >
>> > - moazzam
>> > http://moazzam-khan.com
>> >
>> > On Wed, Jun 16, 2010 at 3:37 AM, Rakhi Khatwani <rk...@gmail.com>
>> wrote:
>> >> Hi,
>> >> I wanted to try out field collapsing for a requirement. i went
>> through
>> >> the wiki and solr-236. but there are lot of patch files. and the
>> comments
>> >> below left me confused.
>> >>
>> >> i tried applyin the patch file on 1.4.0 release but ended up with many
>> >> compile errors.
>> >> i even downloaded the latest code from the repository and applied the
>> >> patch(solr-trunk-236 dtd 16th May 2010). but ended up with build errors.
>> >>
>> >> Can someone tell me which patch file to apply on which build? so that i
>> can
>> >> get collapsing working?
>> >>
>> >> Regards,
>> >> Raakhi.
>> >>
>> >> On Thu, Mar 25, 2010 at 11:15 PM, Rob Z <zm...@hotmail.com> wrote:
>> >>
>> >>>
>> >>> What do you mean you had to revert to Trunk 1.5. Do you mean upgrade?
>> Which
>> >>> version were you using before hand?
>> >>>
>> >>> Can you please list the exact version of 1.5 and the patch # you used.
>> I
>> >>> downloaded the latest nightly build and tried patching using the 2/1
>> patch.
>> >>> Everything went ok but I am getting 1 failing test.
>> >>>
>> >>> Would you recommend using the latest nightly 1.5 build or 1.4 for
>> >>> production use? I really need this feature so I don't think I have much
>> of a
>> >>> choice. Can you also explain the performance implications you are
>> seeing AND
>> >>> what configuration tweaks you've used that helped.
>> >>>
>> >>> Thanks!
>> >>>
>> >>> > From: mark.roberts@red-gate.com
>> >>> > To: solr-user@lucene.apache.org
>> >>> > Date: Thu, 25 Mar 2010 15:21:54 +0000
>> >>> > Subject: RE: Field Collapsing SOLR-236
>> >>> >
>> >>> > Yeah got it working fine - but I needed to revert to Trunk (1.5) to
>> get
>> >>> the patch to apply.
>> >>> >
>> >>> > It does certainly have some performance implications, but tweaking
>> >>> configuration can help here.
>> >>> >
>> >>> > Overall the benefits very much outweigh the costs for us :)
>> >>> >
>> >>> > Mark.
>> >>> >
>> >>> >
>> >>> > -----Original Message-----
>> >>> > From: Dennis Gearon [mailto:gearond@sbcglobal.net]
>> >>> > Sent: 25 March 2010 00:49
>> >>> > To: solr-user@lucene.apache.org
>> >>> > Subject: Re: Field Collapsing SOLR-236
>> >>> >
>> >>> > Boy, I hope that field collapsing works! I'm planning on using it
>> >>> heavily.
>> >>> > Dennis Gearon
>> >>> >
>> >>> > Signature Warning
>> >>> > ----------------
>> >>> > EARTH has a Right To Life,
>> >>> > otherwise we all die.
>> >>> >
>> >>> > Read 'Hot, Flat, and Crowded'
>> >>> > Laugh at http://www.yert.com/film.php
>> >>> >
>> >>> >
>> >>> > --- On Wed, 3/24/10, blargy <zm...@hotmail.com> wrote:
>> >>> >
>> >>> > > From: blargy <zm...@hotmail.com>
>> >>> > > Subject: Field Collapsing SOLR-236
>> >>> > > To: solr-user@lucene.apache.org
>> >>> > > Date: Wednesday, March 24, 2010, 12:17 PM
>> >>> > >
>> >>> > > Has anyone had any luck with the field collapsing patch
>> >>> > > (SOLR-236) with Solr
>> >>> > > 1.4? I tried patching my version of 1.4 with no such luck.
>> >>> > >
>> >>> > > Thanks
>> >>> > > --
>> >>> > > View this message in context:
>> >>>
>> http://old.nabble.com/Field-Collapsing-SOLR-236-tp28019949p28019949.html
>> >>> > > Sent from the Solr - User mailing list archive at
>> >>> > > Nabble.com.
>> >>> > >
>> >>> > >
>> >>>
>> >>> _________________________________________________________________
>> >>> Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
>> >>> http://clk.atdmt.com/GBL/go/210850552/direct/01/
>> >>>
>> >>
>> >
>>
>
Re: Field Collapsing SOLR-236
Posted by Eric Caron <er...@gmail.com>.
I've had the best luck checking out the newest Solr/Lucene (so the 1.5-line)
from SVN, then just doing "patch -p0 < SOLR-236-trunk.patch" from inside the
trunk directory. I just did it against the newest checkout and it works fine
still.
On Wed, Jun 16, 2010 at 11:35 AM, Moazzam Khan <mo...@gmail.com> wrote:
> Actually I take that back. I am just as lost as you. I wish there was
> a tutorial on how to do this (although I get the feeling that once I
> know how to do it I will go "ohh... I can't believe I couldn't figure
> that out")
>
> - Moazzam
>
> On Wed, Jun 16, 2010 at 8:25 AM, Moazzam Khan <mo...@gmail.com> wrote:
> > Hi Rakhi,
> >
> > You are supposed to get the code for solr 1.4 from SVN here:
> > http:/svn.apache.org/repos/asf/lucene/solr/tags/
> >
> > Then apply the path to it and comppile. It should work.
> >
> >
> > However, you will probably get an error at run time saying some java
> > class is missing. I haven't been able to figure out what to do after
> > that.
> >
> >
> >
> > - moazzam
> > http://moazzam-khan.com
> >
> > On Wed, Jun 16, 2010 at 3:37 AM, Rakhi Khatwani <rk...@gmail.com>
> wrote:
> >> Hi,
> >> I wanted to try out field collapsing for a requirement. i went
> through
> >> the wiki and solr-236. but there are lot of patch files. and the
> comments
> >> below left me confused.
> >>
> >> i tried applyin the patch file on 1.4.0 release but ended up with many
> >> compile errors.
> >> i even downloaded the latest code from the repository and applied the
> >> patch(solr-trunk-236 dtd 16th May 2010). but ended up with build errors.
> >>
> >> Can someone tell me which patch file to apply on which build? so that i
> can
> >> get collapsing working?
> >>
> >> Regards,
> >> Raakhi.
> >>
> >> On Thu, Mar 25, 2010 at 11:15 PM, Rob Z <zm...@hotmail.com> wrote:
> >>
> >>>
> >>> What do you mean you had to revert to Trunk 1.5. Do you mean upgrade?
> Which
> >>> version were you using before hand?
> >>>
> >>> Can you please list the exact version of 1.5 and the patch # you used.
> I
> >>> downloaded the latest nightly build and tried patching using the 2/1
> patch.
> >>> Everything went ok but I am getting 1 failing test.
> >>>
> >>> Would you recommend using the latest nightly 1.5 build or 1.4 for
> >>> production use? I really need this feature so I don't think I have much
> of a
> >>> choice. Can you also explain the performance implications you are
> seeing AND
> >>> what configuration tweaks you've used that helped.
> >>>
> >>> Thanks!
> >>>
> >>> > From: mark.roberts@red-gate.com
> >>> > To: solr-user@lucene.apache.org
> >>> > Date: Thu, 25 Mar 2010 15:21:54 +0000
> >>> > Subject: RE: Field Collapsing SOLR-236
> >>> >
> >>> > Yeah got it working fine - but I needed to revert to Trunk (1.5) to
> get
> >>> the patch to apply.
> >>> >
> >>> > It does certainly have some performance implications, but tweaking
> >>> configuration can help here.
> >>> >
> >>> > Overall the benefits very much outweigh the costs for us :)
> >>> >
> >>> > Mark.
> >>> >
> >>> >
> >>> > -----Original Message-----
> >>> > From: Dennis Gearon [mailto:gearond@sbcglobal.net]
> >>> > Sent: 25 March 2010 00:49
> >>> > To: solr-user@lucene.apache.org
> >>> > Subject: Re: Field Collapsing SOLR-236
> >>> >
> >>> > Boy, I hope that field collapsing works! I'm planning on using it
> >>> heavily.
> >>> > Dennis Gearon
> >>> >
> >>> > Signature Warning
> >>> > ----------------
> >>> > EARTH has a Right To Life,
> >>> > otherwise we all die.
> >>> >
> >>> > Read 'Hot, Flat, and Crowded'
> >>> > Laugh at http://www.yert.com/film.php
> >>> >
> >>> >
> >>> > --- On Wed, 3/24/10, blargy <zm...@hotmail.com> wrote:
> >>> >
> >>> > > From: blargy <zm...@hotmail.com>
> >>> > > Subject: Field Collapsing SOLR-236
> >>> > > To: solr-user@lucene.apache.org
> >>> > > Date: Wednesday, March 24, 2010, 12:17 PM
> >>> > >
> >>> > > Has anyone had any luck with the field collapsing patch
> >>> > > (SOLR-236) with Solr
> >>> > > 1.4? I tried patching my version of 1.4 with no such luck.
> >>> > >
> >>> > > Thanks
> >>> > > --
> >>> > > View this message in context:
> >>>
> http://old.nabble.com/Field-Collapsing-SOLR-236-tp28019949p28019949.html
> >>> > > Sent from the Solr - User mailing list archive at
> >>> > > Nabble.com.
> >>> > >
> >>> > >
> >>>
> >>> _________________________________________________________________
> >>> Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
> >>> http://clk.atdmt.com/GBL/go/210850552/direct/01/
> >>>
> >>
> >
>
Re: Field Collapsing SOLR-236
Posted by Moazzam Khan <mo...@gmail.com>.
Actually I take that back. I am just as lost as you. I wish there was
a tutorial on how to do this (although I get the feeling that once I
know how to do it I will go "ohh... I can't believe I couldn't figure
that out")
- Moazzam
On Wed, Jun 16, 2010 at 8:25 AM, Moazzam Khan <mo...@gmail.com> wrote:
> Hi Rakhi,
>
> You are supposed to get the code for solr 1.4 from SVN here:
> http:/svn.apache.org/repos/asf/lucene/solr/tags/
>
> Then apply the path to it and comppile. It should work.
>
>
> However, you will probably get an error at run time saying some java
> class is missing. I haven't been able to figure out what to do after
> that.
>
>
>
> - moazzam
> http://moazzam-khan.com
>
> On Wed, Jun 16, 2010 at 3:37 AM, Rakhi Khatwani <rk...@gmail.com> wrote:
>> Hi,
>> I wanted to try out field collapsing for a requirement. i went through
>> the wiki and solr-236. but there are lot of patch files. and the comments
>> below left me confused.
>>
>> i tried applyin the patch file on 1.4.0 release but ended up with many
>> compile errors.
>> i even downloaded the latest code from the repository and applied the
>> patch(solr-trunk-236 dtd 16th May 2010). but ended up with build errors.
>>
>> Can someone tell me which patch file to apply on which build? so that i can
>> get collapsing working?
>>
>> Regards,
>> Raakhi.
>>
>> On Thu, Mar 25, 2010 at 11:15 PM, Rob Z <zm...@hotmail.com> wrote:
>>
>>>
>>> What do you mean you had to revert to Trunk 1.5. Do you mean upgrade? Which
>>> version were you using before hand?
>>>
>>> Can you please list the exact version of 1.5 and the patch # you used. I
>>> downloaded the latest nightly build and tried patching using the 2/1 patch.
>>> Everything went ok but I am getting 1 failing test.
>>>
>>> Would you recommend using the latest nightly 1.5 build or 1.4 for
>>> production use? I really need this feature so I don't think I have much of a
>>> choice. Can you also explain the performance implications you are seeing AND
>>> what configuration tweaks you've used that helped.
>>>
>>> Thanks!
>>>
>>> > From: mark.roberts@red-gate.com
>>> > To: solr-user@lucene.apache.org
>>> > Date: Thu, 25 Mar 2010 15:21:54 +0000
>>> > Subject: RE: Field Collapsing SOLR-236
>>> >
>>> > Yeah got it working fine - but I needed to revert to Trunk (1.5) to get
>>> the patch to apply.
>>> >
>>> > It does certainly have some performance implications, but tweaking
>>> configuration can help here.
>>> >
>>> > Overall the benefits very much outweigh the costs for us :)
>>> >
>>> > Mark.
>>> >
>>> >
>>> > -----Original Message-----
>>> > From: Dennis Gearon [mailto:gearond@sbcglobal.net]
>>> > Sent: 25 March 2010 00:49
>>> > To: solr-user@lucene.apache.org
>>> > Subject: Re: Field Collapsing SOLR-236
>>> >
>>> > Boy, I hope that field collapsing works! I'm planning on using it
>>> heavily.
>>> > Dennis Gearon
>>> >
>>> > Signature Warning
>>> > ----------------
>>> > EARTH has a Right To Life,
>>> > otherwise we all die.
>>> >
>>> > Read 'Hot, Flat, and Crowded'
>>> > Laugh at http://www.yert.com/film.php
>>> >
>>> >
>>> > --- On Wed, 3/24/10, blargy <zm...@hotmail.com> wrote:
>>> >
>>> > > From: blargy <zm...@hotmail.com>
>>> > > Subject: Field Collapsing SOLR-236
>>> > > To: solr-user@lucene.apache.org
>>> > > Date: Wednesday, March 24, 2010, 12:17 PM
>>> > >
>>> > > Has anyone had any luck with the field collapsing patch
>>> > > (SOLR-236) with Solr
>>> > > 1.4? I tried patching my version of 1.4 with no such luck.
>>> > >
>>> > > Thanks
>>> > > --
>>> > > View this message in context:
>>> http://old.nabble.com/Field-Collapsing-SOLR-236-tp28019949p28019949.html
>>> > > Sent from the Solr - User mailing list archive at
>>> > > Nabble.com.
>>> > >
>>> > >
>>>
>>> _________________________________________________________________
>>> Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
>>> http://clk.atdmt.com/GBL/go/210850552/direct/01/
>>>
>>
>
Re: Field Collapsing SOLR-236
Posted by Moazzam Khan <mo...@gmail.com>.
Hi Rakhi,
You are supposed to get the code for solr 1.4 from SVN here:
http:/svn.apache.org/repos/asf/lucene/solr/tags/
Then apply the path to it and comppile. It should work.
However, you will probably get an error at run time saying some java
class is missing. I haven't been able to figure out what to do after
that.
- moazzam
http://moazzam-khan.com
On Wed, Jun 16, 2010 at 3:37 AM, Rakhi Khatwani <rk...@gmail.com> wrote:
> Hi,
> I wanted to try out field collapsing for a requirement. i went through
> the wiki and solr-236. but there are lot of patch files. and the comments
> below left me confused.
>
> i tried applyin the patch file on 1.4.0 release but ended up with many
> compile errors.
> i even downloaded the latest code from the repository and applied the
> patch(solr-trunk-236 dtd 16th May 2010). but ended up with build errors.
>
> Can someone tell me which patch file to apply on which build? so that i can
> get collapsing working?
>
> Regards,
> Raakhi.
>
> On Thu, Mar 25, 2010 at 11:15 PM, Rob Z <zm...@hotmail.com> wrote:
>
>>
>> What do you mean you had to revert to Trunk 1.5. Do you mean upgrade? Which
>> version were you using before hand?
>>
>> Can you please list the exact version of 1.5 and the patch # you used. I
>> downloaded the latest nightly build and tried patching using the 2/1 patch.
>> Everything went ok but I am getting 1 failing test.
>>
>> Would you recommend using the latest nightly 1.5 build or 1.4 for
>> production use? I really need this feature so I don't think I have much of a
>> choice. Can you also explain the performance implications you are seeing AND
>> what configuration tweaks you've used that helped.
>>
>> Thanks!
>>
>> > From: mark.roberts@red-gate.com
>> > To: solr-user@lucene.apache.org
>> > Date: Thu, 25 Mar 2010 15:21:54 +0000
>> > Subject: RE: Field Collapsing SOLR-236
>> >
>> > Yeah got it working fine - but I needed to revert to Trunk (1.5) to get
>> the patch to apply.
>> >
>> > It does certainly have some performance implications, but tweaking
>> configuration can help here.
>> >
>> > Overall the benefits very much outweigh the costs for us :)
>> >
>> > Mark.
>> >
>> >
>> > -----Original Message-----
>> > From: Dennis Gearon [mailto:gearond@sbcglobal.net]
>> > Sent: 25 March 2010 00:49
>> > To: solr-user@lucene.apache.org
>> > Subject: Re: Field Collapsing SOLR-236
>> >
>> > Boy, I hope that field collapsing works! I'm planning on using it
>> heavily.
>> > Dennis Gearon
>> >
>> > Signature Warning
>> > ----------------
>> > EARTH has a Right To Life,
>> > otherwise we all die.
>> >
>> > Read 'Hot, Flat, and Crowded'
>> > Laugh at http://www.yert.com/film.php
>> >
>> >
>> > --- On Wed, 3/24/10, blargy <zm...@hotmail.com> wrote:
>> >
>> > > From: blargy <zm...@hotmail.com>
>> > > Subject: Field Collapsing SOLR-236
>> > > To: solr-user@lucene.apache.org
>> > > Date: Wednesday, March 24, 2010, 12:17 PM
>> > >
>> > > Has anyone had any luck with the field collapsing patch
>> > > (SOLR-236) with Solr
>> > > 1.4? I tried patching my version of 1.4 with no such luck.
>> > >
>> > > Thanks
>> > > --
>> > > View this message in context:
>> http://old.nabble.com/Field-Collapsing-SOLR-236-tp28019949p28019949.html
>> > > Sent from the Solr - User mailing list archive at
>> > > Nabble.com.
>> > >
>> > >
>>
>> _________________________________________________________________
>> Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
>> http://clk.atdmt.com/GBL/go/210850552/direct/01/
>>
>
Re: Field Collapsing SOLR-236
Posted by Rakhi Khatwani <rk...@gmail.com>.
Hi Mozzam,
I finally got it working....
Thanks a ton guys :)
Regards
Raakhi
On Sat, Jul 10, 2010 at 10:45 AM, Moazzam Khan <mo...@gmail.com> wrote:
> Hi Rakhi,
>
> Sorry, I didn't see this email until just now. Did you get it working?
>
>
> If not here's some things that might help.
>
>
> - Download the patch first.
> - Check the date on which the patch was released.
> - Download the version of the trunk that existed at that date.
> - Apply the patch using the patch program in linux. There is a Windows
> program for patching but I can't remember right now.
> - After applying the patch just compile the whole thing
>
>
> It might be better if you used the example folder first and modify the
> config to work for multicore (at least that's what I did) . You can
> compile example by doing
>
> ant example
>
> (if I remember correctly)
>
> For config stuff refer to this link :
>
> http://wiki.apache.org/solr/FieldCollapsing
>
>
> HTH :)
>
> - Moazzam
>
>
> I'd give you the
>
>
>
> On Wed, Jun 23, 2010 at 7:23 AM, Rakhi Khatwani <rk...@gmail.com>
> wrote:
> > Hi,
> > But these is almost no settings in my config
> > heres a snapshot of what i have in my solrconfig.xml
> >
> > <config>
> > <updateHandler class="solr.DirectUpdateHandler2" />
> >
> > <requestDispatcher handleSelect="true" >
> > <requestParsers enableRemoteStreaming="false"
> > multipartUploadLimitInKB="2048" />
> > </requestDispatcher>
> >
> > <requestHandler name="standard" class="solr.StandardRequestHandler"
> > default="true" />
> > <requestHandler name="/update" class="solr.XmlUpdateRequestHandler" />
> > <requestHandler name="/admin/"
> > class="org.apache.solr.handler.admin.AdminHandlers" />
> >
> > <!-- config for the admin interface -->
> > <admin>
> > <defaultQuery>*:*</defaultQuery>
> > </admin>
> >
> > <!-- config for field collapsing -->
> > <searchComponent name="query"
> > class="org.apache.solr.handler.component.CollapseComponent" />
> > </config>
> >
> > Am i goin wrong anywhere?
> > Regards,
> > Raakhi
> >
> > On Wed, Jun 23, 2010 at 3:28 PM, Govind Kanshi <govind.kanshi@gmail.com
> >wrote:
> >
> >> fieldType:analyzer without class or tokenizer & filter list seems to
> point
> >> to the config - you may want to correct.
> >>
> >>
> >> On Wed, Jun 23, 2010 at 3:09 PM, Rakhi Khatwani <rk...@gmail.com>
> >> wrote:
> >>
> >> > Hi,
> >> > I checked out modules & lucene from the trunk.
> >> > Performed a build using the following commands
> >> > ant clean
> >> > ant compile
> >> > ant example
> >> >
> >> > Which compiled successfully.
> >> >
> >> >
> >> > I then put my existing index(using schema.xml from
> solr1.4.0/conf/solr/)
> >> in
> >> > the multicore folder, configured solr.xml and started the server
> >> >
> >> > When i type in http://localhost:8983/solr
> >> >
> >> > i get the following error:
> >> > org.apache.solr.common.SolrException: Plugin init failure for
> >> [schema.xml]
> >> > fieldType:analyzer without class or tokenizer & filter list
> >> > at
> >> >
> >> >
> >>
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:168)
> >> > at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:480)
> >> > at org.apache.solr.schema.IndexSchema.<init>(IndexSchema.java:122)
> >> > at org.apache.solr.core.CoreContainer.create(CoreContainer.java:429)
> >> > at org.apache.solr.core.CoreContainer.load(CoreContainer.java:286)
> >> > at org.apache.solr.core.CoreContainer.load(CoreContainer.java:198)
> >> > at
> >> >
> >> >
> >>
> org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:123)
> >> > at
> >> >
> >>
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:86)
> >> > at
> org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
> >> > at
> >> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> >> > at
> >> >
> >> >
> >>
> org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:662)
> >> > at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
> >> > at
> >> >
> >> >
> >>
> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
> >> > at
> >> >
> org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
> >> > at
> org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
> >> > at
> >> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> >> > at
> >> >
> >> >
> >>
> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
> >> > at
> >> >
> >> >
> >>
> org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
> >> > at
> >> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> >> > at
> >> >
> >> >
> >>
> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
> >> > at
> >> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> >> > at
> >> >
> org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
> >> > at org.mortbay.jetty.Server.doStart(Server.java:224)
> >> > at
> >> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> >> > at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
> >> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> > at
> >> >
> >> >
> >>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> >> > at
> >> >
> >> >
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >> > at java.lang.reflect.Method.invoke(Method.java:597)
> >> > at org.mortbay.start.Main.invokeMain(Main.java:194)
> >> > at org.mortbay.start.Main.start(Main.java:534)
> >> > at org.mortbay.start.Main.start(Main.java:441)
> >> > at org.mortbay.start.Main.main(Main.java:119)
> >> > Caused by: org.apache.solr.common.SolrException: analyzer without
> class
> >> or
> >> > tokenizer & filter list
> >> > at
> org.apache.solr.schema.IndexSchema.readAnalyzer(IndexSchema.java:908)
> >> > at org.apache.solr.schema.IndexSchema.access$100(IndexSchema.java:60)
> >> > at org.apache.solr.schema.IndexSchema$1.create(IndexSchema.java:450)
> >> > at org.apache.solr.schema.IndexSchema$1.create(IndexSchema.java:435)
> >> > at
> >> >
> >> >
> >>
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:142)
> >> > ... 32 more
> >> >
> >> >
> >> > Then i picked up an existing index (schema.xml from solr1.3/solr/conf)
> >> and
> >> > put it in multicore folder, configured solr.xml and restarted my index
> >> >
> >> > Collapsing worked fine.
> >> >
> >> > Any pointers, which part of schema.xml (solr 1.4) is causing this
> >> > exception?
> >> >
> >> > Regards,
> >> > Raakhi
> >> >
> >> >
> >> >
> >> > On Wed, Jun 23, 2010 at 1:35 PM, Rakhi Khatwani <rk...@gmail.com>
> >> > wrote:
> >> >
> >> > >
> >> > > 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 <rk...@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 <rk...@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 <rk...@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
> >> > >>> >> >> >> <ma...@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
> >> > >>>
> >> > >>
> >> > >>
> >> > >
> >> >
> >>
> >
>
Re: Field Collapsing SOLR-236
Posted by Moazzam Khan <mo...@gmail.com>.
Hi Rakhi,
Sorry, I didn't see this email until just now. Did you get it working?
If not here's some things that might help.
- Download the patch first.
- Check the date on which the patch was released.
- Download the version of the trunk that existed at that date.
- Apply the patch using the patch program in linux. There is a Windows
program for patching but I can't remember right now.
- After applying the patch just compile the whole thing
It might be better if you used the example folder first and modify the
config to work for multicore (at least that's what I did) . You can
compile example by doing
ant example
(if I remember correctly)
For config stuff refer to this link :
http://wiki.apache.org/solr/FieldCollapsing
HTH :)
- Moazzam
I'd give you the
On Wed, Jun 23, 2010 at 7:23 AM, Rakhi Khatwani <rk...@gmail.com> wrote:
> Hi,
> But these is almost no settings in my config
> heres a snapshot of what i have in my solrconfig.xml
>
> <config>
> <updateHandler class="solr.DirectUpdateHandler2" />
>
> <requestDispatcher handleSelect="true" >
> <requestParsers enableRemoteStreaming="false"
> multipartUploadLimitInKB="2048" />
> </requestDispatcher>
>
> <requestHandler name="standard" class="solr.StandardRequestHandler"
> default="true" />
> <requestHandler name="/update" class="solr.XmlUpdateRequestHandler" />
> <requestHandler name="/admin/"
> class="org.apache.solr.handler.admin.AdminHandlers" />
>
> <!-- config for the admin interface -->
> <admin>
> <defaultQuery>*:*</defaultQuery>
> </admin>
>
> <!-- config for field collapsing -->
> <searchComponent name="query"
> class="org.apache.solr.handler.component.CollapseComponent" />
> </config>
>
> Am i goin wrong anywhere?
> Regards,
> Raakhi
>
> On Wed, Jun 23, 2010 at 3:28 PM, Govind Kanshi <go...@gmail.com>wrote:
>
>> fieldType:analyzer without class or tokenizer & filter list seems to point
>> to the config - you may want to correct.
>>
>>
>> On Wed, Jun 23, 2010 at 3:09 PM, Rakhi Khatwani <rk...@gmail.com>
>> wrote:
>>
>> > Hi,
>> > I checked out modules & lucene from the trunk.
>> > Performed a build using the following commands
>> > ant clean
>> > ant compile
>> > ant example
>> >
>> > Which compiled successfully.
>> >
>> >
>> > I then put my existing index(using schema.xml from solr1.4.0/conf/solr/)
>> in
>> > the multicore folder, configured solr.xml and started the server
>> >
>> > When i type in http://localhost:8983/solr
>> >
>> > i get the following error:
>> > org.apache.solr.common.SolrException: Plugin init failure for
>> [schema.xml]
>> > fieldType:analyzer without class or tokenizer & filter list
>> > at
>> >
>> >
>> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:168)
>> > at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:480)
>> > at org.apache.solr.schema.IndexSchema.<init>(IndexSchema.java:122)
>> > at org.apache.solr.core.CoreContainer.create(CoreContainer.java:429)
>> > at org.apache.solr.core.CoreContainer.load(CoreContainer.java:286)
>> > at org.apache.solr.core.CoreContainer.load(CoreContainer.java:198)
>> > at
>> >
>> >
>> org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:123)
>> > at
>> >
>> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:86)
>> > at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
>> > at
>> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>> > at
>> >
>> >
>> org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:662)
>> > at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
>> > at
>> >
>> >
>> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
>> > at
>> > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
>> > at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
>> > at
>> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>> > at
>> >
>> >
>> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
>> > at
>> >
>> >
>> org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
>> > at
>> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>> > at
>> >
>> >
>> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
>> > at
>> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>> > at
>> > org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
>> > at org.mortbay.jetty.Server.doStart(Server.java:224)
>> > at
>> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>> > at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> > at
>> >
>> >
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> > at
>> >
>> >
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> > at java.lang.reflect.Method.invoke(Method.java:597)
>> > at org.mortbay.start.Main.invokeMain(Main.java:194)
>> > at org.mortbay.start.Main.start(Main.java:534)
>> > at org.mortbay.start.Main.start(Main.java:441)
>> > at org.mortbay.start.Main.main(Main.java:119)
>> > Caused by: org.apache.solr.common.SolrException: analyzer without class
>> or
>> > tokenizer & filter list
>> > at org.apache.solr.schema.IndexSchema.readAnalyzer(IndexSchema.java:908)
>> > at org.apache.solr.schema.IndexSchema.access$100(IndexSchema.java:60)
>> > at org.apache.solr.schema.IndexSchema$1.create(IndexSchema.java:450)
>> > at org.apache.solr.schema.IndexSchema$1.create(IndexSchema.java:435)
>> > at
>> >
>> >
>> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:142)
>> > ... 32 more
>> >
>> >
>> > Then i picked up an existing index (schema.xml from solr1.3/solr/conf)
>> and
>> > put it in multicore folder, configured solr.xml and restarted my index
>> >
>> > Collapsing worked fine.
>> >
>> > Any pointers, which part of schema.xml (solr 1.4) is causing this
>> > exception?
>> >
>> > Regards,
>> > Raakhi
>> >
>> >
>> >
>> > On Wed, Jun 23, 2010 at 1:35 PM, Rakhi Khatwani <rk...@gmail.com>
>> > wrote:
>> >
>> > >
>> > > 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 <rk...@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 <rk...@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 <rk...@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
>> > >>> >> >> >> <ma...@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
>> > >>>
>> > >>
>> > >>
>> > >
>> >
>>
>
Re: Field Collapsing SOLR-236
Posted by Rakhi Khatwani <rk...@gmail.com>.
Hi,
But these is almost no settings in my config
heres a snapshot of what i have in my solrconfig.xml
<config>
<updateHandler class="solr.DirectUpdateHandler2" />
<requestDispatcher handleSelect="true" >
<requestParsers enableRemoteStreaming="false"
multipartUploadLimitInKB="2048" />
</requestDispatcher>
<requestHandler name="standard" class="solr.StandardRequestHandler"
default="true" />
<requestHandler name="/update" class="solr.XmlUpdateRequestHandler" />
<requestHandler name="/admin/"
class="org.apache.solr.handler.admin.AdminHandlers" />
<!-- config for the admin interface -->
<admin>
<defaultQuery>*:*</defaultQuery>
</admin>
<!-- config for field collapsing -->
<searchComponent name="query"
class="org.apache.solr.handler.component.CollapseComponent" />
</config>
Am i goin wrong anywhere?
Regards,
Raakhi
On Wed, Jun 23, 2010 at 3:28 PM, Govind Kanshi <go...@gmail.com>wrote:
> fieldType:analyzer without class or tokenizer & filter list seems to point
> to the config - you may want to correct.
>
>
> On Wed, Jun 23, 2010 at 3:09 PM, Rakhi Khatwani <rk...@gmail.com>
> wrote:
>
> > Hi,
> > I checked out modules & lucene from the trunk.
> > Performed a build using the following commands
> > ant clean
> > ant compile
> > ant example
> >
> > Which compiled successfully.
> >
> >
> > I then put my existing index(using schema.xml from solr1.4.0/conf/solr/)
> in
> > the multicore folder, configured solr.xml and started the server
> >
> > When i type in http://localhost:8983/solr
> >
> > i get the following error:
> > org.apache.solr.common.SolrException: Plugin init failure for
> [schema.xml]
> > fieldType:analyzer without class or tokenizer & filter list
> > at
> >
> >
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:168)
> > at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:480)
> > at org.apache.solr.schema.IndexSchema.<init>(IndexSchema.java:122)
> > at org.apache.solr.core.CoreContainer.create(CoreContainer.java:429)
> > at org.apache.solr.core.CoreContainer.load(CoreContainer.java:286)
> > at org.apache.solr.core.CoreContainer.load(CoreContainer.java:198)
> > at
> >
> >
> org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:123)
> > at
> >
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:86)
> > at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
> > at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> > at
> >
> >
> org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:662)
> > at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
> > at
> >
> >
> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
> > at
> > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
> > at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
> > at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> > at
> >
> >
> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
> > at
> >
> >
> org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
> > at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> > at
> >
> >
> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
> > at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> > at
> > org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
> > at org.mortbay.jetty.Server.doStart(Server.java:224)
> > at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> > at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > at
> >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:597)
> > at org.mortbay.start.Main.invokeMain(Main.java:194)
> > at org.mortbay.start.Main.start(Main.java:534)
> > at org.mortbay.start.Main.start(Main.java:441)
> > at org.mortbay.start.Main.main(Main.java:119)
> > Caused by: org.apache.solr.common.SolrException: analyzer without class
> or
> > tokenizer & filter list
> > at org.apache.solr.schema.IndexSchema.readAnalyzer(IndexSchema.java:908)
> > at org.apache.solr.schema.IndexSchema.access$100(IndexSchema.java:60)
> > at org.apache.solr.schema.IndexSchema$1.create(IndexSchema.java:450)
> > at org.apache.solr.schema.IndexSchema$1.create(IndexSchema.java:435)
> > at
> >
> >
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:142)
> > ... 32 more
> >
> >
> > Then i picked up an existing index (schema.xml from solr1.3/solr/conf)
> and
> > put it in multicore folder, configured solr.xml and restarted my index
> >
> > Collapsing worked fine.
> >
> > Any pointers, which part of schema.xml (solr 1.4) is causing this
> > exception?
> >
> > Regards,
> > Raakhi
> >
> >
> >
> > On Wed, Jun 23, 2010 at 1:35 PM, Rakhi Khatwani <rk...@gmail.com>
> > wrote:
> >
> > >
> > > 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 <rk...@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 <rk...@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 <rk...@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
> > >>> >> >> >> <ma...@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
> > >>>
> > >>
> > >>
> > >
> >
>
Re: Field Collapsing SOLR-236
Posted by Govind Kanshi <go...@gmail.com>.
fieldType:analyzer without class or tokenizer & filter list seems to point
to the config - you may want to correct.
On Wed, Jun 23, 2010 at 3:09 PM, Rakhi Khatwani <rk...@gmail.com> wrote:
> Hi,
> I checked out modules & lucene from the trunk.
> Performed a build using the following commands
> ant clean
> ant compile
> ant example
>
> Which compiled successfully.
>
>
> I then put my existing index(using schema.xml from solr1.4.0/conf/solr/) in
> the multicore folder, configured solr.xml and started the server
>
> When i type in http://localhost:8983/solr
>
> i get the following error:
> org.apache.solr.common.SolrException: Plugin init failure for [schema.xml]
> fieldType:analyzer without class or tokenizer & filter list
> at
>
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:168)
> at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:480)
> at org.apache.solr.schema.IndexSchema.<init>(IndexSchema.java:122)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:429)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:286)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:198)
> at
>
> org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:123)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:86)
> at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at
>
> org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:662)
> at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
> at
>
> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
> at
> org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
> at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at
>
> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
> at
>
> org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at
>
> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at
> org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
> at org.mortbay.jetty.Server.doStart(Server.java:224)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.mortbay.start.Main.invokeMain(Main.java:194)
> at org.mortbay.start.Main.start(Main.java:534)
> at org.mortbay.start.Main.start(Main.java:441)
> at org.mortbay.start.Main.main(Main.java:119)
> Caused by: org.apache.solr.common.SolrException: analyzer without class or
> tokenizer & filter list
> at org.apache.solr.schema.IndexSchema.readAnalyzer(IndexSchema.java:908)
> at org.apache.solr.schema.IndexSchema.access$100(IndexSchema.java:60)
> at org.apache.solr.schema.IndexSchema$1.create(IndexSchema.java:450)
> at org.apache.solr.schema.IndexSchema$1.create(IndexSchema.java:435)
> at
>
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:142)
> ... 32 more
>
>
> Then i picked up an existing index (schema.xml from solr1.3/solr/conf) and
> put it in multicore folder, configured solr.xml and restarted my index
>
> Collapsing worked fine.
>
> Any pointers, which part of schema.xml (solr 1.4) is causing this
> exception?
>
> Regards,
> Raakhi
>
>
>
> On Wed, Jun 23, 2010 at 1:35 PM, Rakhi Khatwani <rk...@gmail.com>
> wrote:
>
> >
> > 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 <rk...@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 <rk...@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 <rk...@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
> >>> >> >> >> <ma...@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
> >>>
> >>
> >>
> >
>
Re: Field Collapsing SOLR-236
Posted by Rakhi Khatwani <rk...@gmail.com>.
Hi,
I checked out modules & lucene from the trunk.
Performed a build using the following commands
ant clean
ant compile
ant example
Which compiled successfully.
I then put my existing index(using schema.xml from solr1.4.0/conf/solr/) in
the multicore folder, configured solr.xml and started the server
When i type in http://localhost:8983/solr
i get the following error:
org.apache.solr.common.SolrException: Plugin init failure for [schema.xml]
fieldType:analyzer without class or tokenizer & filter list
at
org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:168)
at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:480)
at org.apache.solr.schema.IndexSchema.<init>(IndexSchema.java:122)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:429)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:286)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:198)
at
org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:123)
at
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:86)
at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:662)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at
org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:224)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.mortbay.start.Main.invokeMain(Main.java:194)
at org.mortbay.start.Main.start(Main.java:534)
at org.mortbay.start.Main.start(Main.java:441)
at org.mortbay.start.Main.main(Main.java:119)
Caused by: org.apache.solr.common.SolrException: analyzer without class or
tokenizer & filter list
at org.apache.solr.schema.IndexSchema.readAnalyzer(IndexSchema.java:908)
at org.apache.solr.schema.IndexSchema.access$100(IndexSchema.java:60)
at org.apache.solr.schema.IndexSchema$1.create(IndexSchema.java:450)
at org.apache.solr.schema.IndexSchema$1.create(IndexSchema.java:435)
at
org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:142)
... 32 more
Then i picked up an existing index (schema.xml from solr1.3/solr/conf) and
put it in multicore folder, configured solr.xml and restarted my index
Collapsing worked fine.
Any pointers, which part of schema.xml (solr 1.4) is causing this exception?
Regards,
Raakhi
On Wed, Jun 23, 2010 at 1:35 PM, Rakhi Khatwani <rk...@gmail.com> wrote:
>
> 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 <rk...@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 <rk...@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 <rk...@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 <rk...@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
>>> >> >> >> <ma...@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 <er...@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
>>>
>>
>>
>
Re: Field Collapsing SOLR-236
Posted by Rakhi Khatwani <rk...@gmail.com>.
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 <rk...@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 <rk...@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 <rk...@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 <rk...@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
>> >> >> >> <ma...@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 <er...@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
>>
>
>
Re: Field Collapsing SOLR-236
Posted by Rakhi Khatwani <rk...@gmail.com>.
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 <rk...@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 <rk...@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 <rk...@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 <mo...@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
> >> >> >> <ma...@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 <er...@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
>
Re: Field Collapsing SOLR-236
Posted by Martijn v Groningen <ma...@gmail.com>.
What exactly did not work? Patching, compiling or running it?
On 22 June 2010 16:06, Rakhi Khatwani <rk...@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 <rk...@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 <rk...@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 <mo...@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
>> >> >> <ma...@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 <er...@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
Re: Field Collapsing SOLR-236
Posted by Rakhi Khatwani <rk...@gmail.com>.
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 <rk...@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 <rk...@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 <mo...@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
> >> >> <ma...@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 <er...@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
>
Re: Field Collapsing SOLR-236
Posted by Martijn v Groningen <ma...@gmail.com>.
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 <rk...@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 <rk...@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 <mo...@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
>> >> <ma...@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 <er...@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
Re: Field Collapsing SOLR-236
Posted by Rakhi Khatwani <rk...@gmail.com>.
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 <rk...@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 <mo...@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
> >> <ma...@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 <er...@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
> >> >
> >>
> >
>
Re: Field Collapsing SOLR-236
Posted by Martijn v Groningen <ma...@gmail.com>.
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 <rk...@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 <mo...@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
>> <ma...@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 <er...@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
>> >
>>
>
Re: Field Collapsing SOLR-236
Posted by Rakhi Khatwani <rk...@gmail.com>.
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 <mo...@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
> <ma...@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 <er...@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
> >
>
Re: Field Collapsing SOLR-236
Posted by Moazzam Khan <mo...@gmail.com>.
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
<ma...@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 <er...@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
>
Re: Field Collapsing SOLR-236
Posted by Martijn v Groningen <ma...@gmail.com>.
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 <er...@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
Re: Solr Project Structure (was Re: Field Collapsing SOLR-236)
Posted by Erik Hatcher <er...@gmail.com>.
On Jun 17, 2010, at 7:44 PM, Mark Diggory wrote:
> when I saw what was done with the "templating" of the Maven pom
> work that was originally donated to solr, I just cringed at it.
Most of us Solr committers are fairly anti-Maven or ambivalent about
it at best, so it hasn't gotten much TLC, admittedly. But rather than
just cringe, help us fix it if it is still broken. I know Ryan, and
sometimes Grant, care about the POM stuff being right, so I'm sure you
can count on some committer eyes on whatever you have to contribute.
> Ideally, source directories should have a 1 to 1 relationship to
> artifacts that are produced.
You get complete agreement from me on that. Directory structure is
very important. I haven't spent much if any time on Solr's build
myself, alas, and I hear some complaints about it. It certainly could
use a bit more attention.
> This SOLR-236 is a posterchild of an unclear practice or convention
> for how to package customizations to Solr. Really, isn't SOLR-236
> "wanted" enough to warrant that it actually reside in the svn where
> it could be developed properly rather than as a task thats been open
> for "how many years"?! I'd highly recommend the Field Collapsing
> prototype ceased to be managed as patches in a JIRA task and
> actually got some code re-visioning behind it and interim release
> building available.
This is where the new craze of git comes in, I think. These types of
big feature additions to Solr or any Apache project can be developed
in a personal branch, maintained there, version controlled, etc. And
then patched and committed to Solr when ready.
Because of Apache's tighter control on committers, it's not really
feasible to have Apache svn branches for these sorts of things where
non-committers are collaborating.
I cringe at working with patches in JIRA myself - it's difficult and
clunky, for me at least.
> I'll even confess that my "patch cludge" in my maven project to
> apply SOLR-236 to the solr source is not at all a best practice in
> terms of supporting addons to solr. It was simply an attempt to
> compensate.
Pragmatism at its finest. +1
> Ideally, Field Collapsing should have been a separately maintained
> codebase in a separate maven project that did not interfere with the
> solr, solr core request handler or configuration implementations and
> simply just depended on them. Then it could be dropped into a lib
> dir of any solr 1.4.0. (and conversely just added to my webapp poms
> as a maven dependency when they are assembled in our own build
> processes).
I don't know the details of SOLR-236 myself, but I believe it includes
necessary core changes too, so it can't simply be a drop in lib.
>>> 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?
>
> mvn package jetty:run
Oh, and Solr's build has this too:
ant run-example
with optional switches to -D set: example.solr.home, example.data.dir,
example.jetty.port, and some others like running the JVM with
debugging enabled.
>>> 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?
>
> But if I have my own configuration for that Request Handler, how
> many lines of java to I need to add/alter to get that configuration
> to parse in solr config and be available? Even if its just a few,
> its IMO, its still the wrong way to be cutting the cake.
Zero lines of additional Java code. Make your configuration available
as a separate file pointed to by the args available in Solr's config,
or however you want to wire your own configuration in. Maybe I'm
misunderstanding exactly what you want, but request handlers have init
params.
Though, to be technical, most extensions these days are going to be
search components, not request handlers - but the same discussion
applies.
>> 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.
>
> Its an example of something I coin a "policing bottleneck". Where
> the core code introduces a pattern for convenience that restricts
> the ability to add features to the application without "approval"
> I.E. consensus that the code contribution be part of the central
> API. Thus as long as the patch alters core code, you can't make the
> whole solution easily available to your users without complete
> approval.
Well, there's nothing that restricts the ability to add new features,
is there? make a request to Solr via SolrJ generically, and navigate
the response structure. Seems like folks get hung up on expecting
there always be a convenient getSomeSpecialResponseData() method for
every request handler / component out there, and all that does is
clutter up SolrJ, IMO.
> Your welcome to your opinions, I have some pretty strong ones in
> favor of Spring as well. hacking a configuration file is one thing,
> having to alter code to support new configuration properties, well
> that creates a bit of a bottleneck in getting changes into the
> codebase.
Can you lay out an example where you've had to alter code to support
new configuration properties? And perhaps illustrate how Spring would
make it better?
> 1.) Having simple configuration is not really of benefit if it takes
> coding for your users to customize it, which they will, as is seen
> in many of the patches provided to solr. Ultimately, this burdens
> your own efforts to maintain the application and delays in
> processing tasks that have good functional addons in them.
I'm not following this point. What's an example where custom code was
needed?
> 2.) Adopting Spring (or any other IoC/DI framework) forces your
> application code instantiation and binding to be evaluated and
> refactored; this frees how your application is assembled, allows
> your application functional areas to be more cleanly separated, and
> hardens your applications interface contracts. Doing so, in turn,
> allows your application to be assembled and reused inside other
> frameworks and environments, increasing your target user base and
> participation, making your project ultimately, more active and more
> successful.
Don't get me wrong... I'm pro IoC/DI. Solr does need more of that in
order to have it's componentry better factored for unit testing,
extensibility, and pluggability. +1
> So, I think the goal of any development activity around adopting a
> DI framework would be to free up the application from being
> hardbound to the configuration file so those of us that choose to
> use other configuration tools can do so. I even suspect that it
> might be already possible if the instantiation and binding of the
> objects that form a Solr application are sufficiently separate from
> those configuration classes in the first place. A good area to
> explore.
No doubt. +1 again.
>> Oh, and Hi Mark! :)
>
> Your Solr Blackbelt at code4lib was excellent, as were our
> conversations afterward. :-)
Why thank you!
Erik
Solr Project Structure (was Re: Field Collapsing SOLR-236)
Posted by Mark Diggory <md...@gmail.com>.
Erik,
I try not to be exclusionary of others development tool choices in the selection of my own. However, just to surely stir up a nest of hornets in true Apache fashion... when I saw what was done with the "templating" of the Maven pom work that was originally donated to solr, I just cringed at it. The point of using Maven as a build tool is to avoid the complexity that was introduced by "one off'ing" in the manner that was finally committed.
https://issues.apache.org/jira/browse/SOLR-19
https://issues.apache.org/jira/browse/SOLR-586
I choose to do the inverse of the solr build process as a means to manage our own dependency on solr in a Maven way, conventional to our current build and modularity practices. I don't think Solr needs to adopt maven if they prefer ant, just draw clearer lines through the project about how to separate code for functional areas and clearly document the interfaces that should be customizable/changeable. JIRA Tasks should tackle core code changes separately from addon functionality that can be swapped out or left behind such as to avoid the risks of producing "spaghetti" interdependencies in the codebase. And if using Ant, efforts should be made to not do highly complex transformations of the sourcecode and or generated artifacts. Ideally, source directories should have a 1 to 1 relationship to artifacts that are produced.
This SOLR-236 is a posterchild of an unclear practice or convention for how to package customizations to Solr. Really, isn't SOLR-236 "wanted" enough to warrant that it actually reside in the svn where it could be developed properly rather than as a task thats been open for "how many years"?! I'd highly recommend the Field Collapsing prototype ceased to be managed as patches in a JIRA task and actually got some code re-visioning behind it and interim release building available.
I'll even confess that my "patch cludge" in my maven project to apply SOLR-236 to the solr source is not at all a best practice in terms of supporting addons to solr. It was simply an attempt to compensate. Ideally, Field Collapsing should have been a separately maintained codebase in a separate maven project that did not interfere with the solr, solr core request handler or configuration implementations and simply just depended on them. Then it could be dropped into a lib dir of any solr 1.4.0. (and conversely just added to my webapp poms as a maven dependency when they are assembled in our own build processes).
further comments below...
On Jun 17, 2010, at 11:20 AM, Erik Hatcher 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).
Tu chez!
>> 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?
mvn package jetty:run
Its not much different, but it is different in that its webapplication and development tool centric, theres no special startup code, thats just using maven+jetty or your debugging environment to fire up the war for testing.
>> 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?
But if I have my own configuration for that Request Handler, how many lines of java to I need to add/alter to get that configuration to parse in solr config and be available? Even if its just a few, its IMO, its still the wrong way to be cutting the cake.
>
>> 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.
Its an example of something I coin a "policing bottleneck". Where the core code introduces a pattern for convenience that restricts the ability to add features to the application without "approval" I.E. consensus that the code contribution be part of the central API. Thus as long as the patch alters core code, you can't make the whole solution easily available to your users without complete approval.
> 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.
Your welcome to your opinions, I have some pretty strong ones in favor of Spring as well. hacking a configuration file is one thing, having to alter code to support new configuration properties, well that creates a bit of a bottleneck in getting changes into the codebase.
1.) Having simple configuration is not really of benefit if it takes coding for your users to customize it, which they will, as is seen in many of the patches provided to solr. Ultimately, this burdens your own efforts to maintain the application and delays in processing tasks that have good functional addons in them.
2.) Adopting Spring (or any other IoC/DI framework) forces your application code instantiation and binding to be evaluated and refactored; this frees how your application is assembled, allows your application functional areas to be more cleanly separated, and hardens your applications interface contracts. Doing so, in turn, allows your application to be assembled and reused inside other frameworks and environments, increasing your target user base and participation, making your project ultimately, more active and more successful.
So, I think the goal of any development activity around adopting a DI framework would be to free up the application from being hardbound to the configuration file so those of us that choose to use other configuration tools can do so. I even suspect that it might be already possible if the instantiation and binding of the objects that form a Solr application are sufficiently separate from those configuration classes in the first place. A good area to explore.
>
> Oh, and Hi Mark! :)
Your Solr Blackbelt at code4lib was excellent, as were our conversations afterward. :-)
Cheers,
Mark
Re: Field Collapsing SOLR-236
Posted by Erik Hatcher <er...@gmail.com>.
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
Re: Field Collapsing SOLR-236
Posted by Mark Diggory <md...@gmail.com>.
Blargy?
I produced a patched version of Solr 1.4 and released it into the maven central repository under our DSpace groupid as a dependency for our applications. Your welcome to test it out and use our code for examples. Although, it is not the most recent patch of Field Collapsing, it has been sufficient for our work until then FeildCollapsing solution is finalized.
Solr 1.4 + FieldCollapse Patch
http://scm.dspace.org/svn/repo/modules/dspace-solr/trunk/
http://scm.dspace.org/svn/repo/modules/dspace-discovery/trunk/
I have just recently made the release available...
http://repo2.maven.org/maven2/org/dspace/dependencies/solr/
Mark
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. 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. 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. 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.
On Jun 16, 2010, at 1:37 AM, Rakhi Khatwani wrote:
> Hi,
> I wanted to try out field collapsing for a requirement. i went through
> the wiki and solr-236. but there are lot of patch files. and the comments
> below left me confused.
>
> i tried applyin the patch file on 1.4.0 release but ended up with many
> compile errors.
> i even downloaded the latest code from the repository and applied the
> patch(solr-trunk-236 dtd 16th May 2010). but ended up with build errors.
>
> Can someone tell me which patch file to apply on which build? so that i can
> get collapsing working?
>
> Regards,
> Raakhi.
>
> On Thu, Mar 25, 2010 at 11:15 PM, Rob Z <zm...@hotmail.com> wrote:
>
>>
>> What do you mean you had to revert to Trunk 1.5. Do you mean upgrade? Which
>> version were you using before hand?
>>
>> Can you please list the exact version of 1.5 and the patch # you used. I
>> downloaded the latest nightly build and tried patching using the 2/1 patch.
>> Everything went ok but I am getting 1 failing test.
>>
>> Would you recommend using the latest nightly 1.5 build or 1.4 for
>> production use? I really need this feature so I don't think I have much of a
>> choice. Can you also explain the performance implications you are seeing AND
>> what configuration tweaks you've used that helped.
>>
>> Thanks!
>>
>>> From: mark.roberts@red-gate.com
>>> To: solr-user@lucene.apache.org
>>> Date: Thu, 25 Mar 2010 15:21:54 +0000
>>> Subject: RE: Field Collapsing SOLR-236
>>>
>>> Yeah got it working fine - but I needed to revert to Trunk (1.5) to get
>> the patch to apply.
>>>
>>> It does certainly have some performance implications, but tweaking
>> configuration can help here.
>>>
>>> Overall the benefits very much outweigh the costs for us :)
>>>
>>> Mark.
>>>
>>>
>>> -----Original Message-----
>>> From: Dennis Gearon [mailto:gearond@sbcglobal.net]
>>> Sent: 25 March 2010 00:49
>>> To: solr-user@lucene.apache.org
>>> Subject: Re: Field Collapsing SOLR-236
>>>
>>> Boy, I hope that field collapsing works! I'm planning on using it
>> heavily.
>>> Dennis Gearon
>>>
>>> Signature Warning
>>> ----------------
>>> EARTH has a Right To Life,
>>> otherwise we all die.
>>>
>>> Read 'Hot, Flat, and Crowded'
>>> Laugh at http://www.yert.com/film.php
>>>
>>>
>>> --- On Wed, 3/24/10, blargy <zm...@hotmail.com> wrote:
>>>
>>>> From: blargy <zm...@hotmail.com>
>>>> Subject: Field Collapsing SOLR-236
>>>> To: solr-user@lucene.apache.org
>>>> Date: Wednesday, March 24, 2010, 12:17 PM
>>>>
>>>> Has anyone had any luck with the field collapsing patch
>>>> (SOLR-236) with Solr
>>>> 1.4? I tried patching my version of 1.4 with no such luck.
>>>>
>>>> Thanks
>>>> --
>>>> View this message in context:
>> http://old.nabble.com/Field-Collapsing-SOLR-236-tp28019949p28019949.html
>>>> Sent from the Solr - User mailing list archive at
>>>> Nabble.com.
>>>>
>>>>
>>
>> _________________________________________________________________
>> Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
>> http://clk.atdmt.com/GBL/go/210850552/direct/01/
>>