[jira] Resolved: (SOLR-255) RemoteSearchable for Solr(use RMI)
[
https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otis Gospodnetic resolved SOLR-255.
---
Resolution: Won't Fix
One month no follow-up makes me think there is no real interest in this any
more, now that we have Distributed Search functionality. If there is still
something of value in this issue/patch, we can reopen.
> RemoteSearchable for Solr(use RMI)
> --
>
> Key: SOLR-255
> URL: https://issues.apache.org/jira/browse/SOLR-255
> Project: Solr
> Issue Type: Improvement
> Components: search
>Reporter: Toru Matsuzawa
>Assignee: Otis Gospodnetic
> Attachments: solr-multi20070606.zip, solr-multi20070724..zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a tag.
>
> E:\sample\data1
> E:\sample\data2
> rmi://localhost
>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the is
> updated,
> that document data in the index will be deleted and data of the updated
> document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from
> SolrCore
> by specifying "< remoteSearcher>true" in solrconfig.xml.(It
> is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
> What should be done?
> - Are there any other considerations about this issue, which I have
> overlooked?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-536) Automatic binding of results to Beans (for solrj)
[
https://issues.apache.org/jira/browse/SOLR-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-536:
Attachment: SOLR-536.patch
Adds methods to SolrServer to directly add beans to Solr
all _add()_ has a corresponding _addBean_ method
This can help mask people from SolrinputDocument, DocumentObjectBinder etc .a
*non-static* field is added to _SolrServer_
{code:java}
private DocumentObjectBinder binder;
{code}
> Automatic binding of results to Beans (for solrj)
> -
>
> Key: SOLR-536
> URL: https://issues.apache.org/jira/browse/SOLR-536
> Project: Solr
> Issue Type: New Feature
> Components: clients - java
>Affects Versions: 1.3
>Reporter: Noble Paul
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 1.3
>
> Attachments: SOLR-536.patch, SOLR-536.patch, SOLR-536.patch,
> SOLR-536.patch
>
>
> as we are using java5 .we can use annotations to bind SolrDocument to java
> beans directly.
> This can make the usage of solrj a bit simpler
> The QueryResponse class in solrj can have an extra method as follows
> public List getResultBeans(Class klass)
> and the bean can have annotations as
> class MyBean{
> @Field("id") //name is optional
> String id;
> @Field("category")
> List categories
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-554) Hierarchical JDK log level selector for SOLR Admin
[ https://issues.apache.org/jira/browse/SOLR-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic updated SOLR-554: -- Fix Version/s: 1.3 My feeling is we should go ahead with this change for now (for 1.3) and it it becomes obsolete or needs changing later, for 1.4, we can deal with that then. I'm not assigning this to myself since I stayed out of the whole logging discussion, but I'm marking it for 1.3, so somebody will handle this one way or the other prior to 1.3. > Hierarchical JDK log level selector for SOLR Admin > -- > > Key: SOLR-554 > URL: https://issues.apache.org/jira/browse/SOLR-554 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Sean Timm >Priority: Minor > Fix For: 1.3 > > Attachments: LogLevelSelection.java, SOLR-554-screenshot-3.jpg, > SOLR-554.patch, SOLR-554.patch, SOLR-554.patch > > > An admin web page to allow displaying and setting the log level of > hierarchical loggers from the UI at runtime. The existing logging.jsp only > sets and displays the root log level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-572: - Attachment: SOLR-572.patch Adds collation Slight change in SpellingResult results to take advantage of a LinkedHashMap and to explicitly state in the contract that spelling suggestions are in order by best suggestion first. Also added some more javadocs. Getting much closer. I'd like to see LUCENE-1297 addressed and committed so it could be used in the Lucene SCs. I've used this API to implement my own spell checker, too, so I'm pretty happy w/ the API if others are. I'd like to commit in the next week or so, so if people can check it out, kick the tires, that would be great. > Spell Checker as a Search Component > --- > > Key: SOLR-572 > URL: https://issues.apache.org/jira/browse/SOLR-572 > Project: Solr > Issue Type: New Feature > Components: spellchecker >Affects Versions: 1.3 >Reporter: Shalin Shekhar Mangar >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch > > > Expose the Lucene contrib SpellChecker as a Search Component. Provide the > following features: > * Allow creating a spell index on a given field and make it possible to have > multiple spell indices -- one for each field > * Give suggestions on a per-field basis > * Given a multi-word query, give only one consistent suggestion > * Process the query with the same analyzer specified for the source field and > process each token separately > * Allow the user to specify minimum length for a token (optional) > Consistency criteria for a multi-word query can consist of the following: > * Preserve the correct words in the original query as it is > * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604062#action_12604062 ] Otis Gospodnetic commented on SOLR-572: --- I think the frequency awareness may be interesting. What happens if "gilf" has a frequency of 95K and "golf" a freq of 100K? Do we need this to become a SCRH config setting expressed as a percentage? (e.g. "Show alternative word suggestions even if the input word exists in the index iff freq(input word)/freq(suggested word)*100 < N%?) > Spell Checker as a Search Component > --- > > Key: SOLR-572 > URL: https://issues.apache.org/jira/browse/SOLR-572 > Project: Solr > Issue Type: New Feature > Components: spellchecker >Affects Versions: 1.3 >Reporter: Shalin Shekhar Mangar >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch > > > Expose the Lucene contrib SpellChecker as a Search Component. Provide the > following features: > * Allow creating a spell index on a given field and make it possible to have > multiple spell indices -- one for each field > * Give suggestions on a per-field basis > * Given a multi-word query, give only one consistent suggestion > * Process the query with the same analyzer specified for the source field and > process each token separately > * Allow the user to specify minimum length for a token (optional) > Consistency criteria for a multi-word query can consist of the following: > * Preserve the correct words in the original query as it is > * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[
https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604060#action_12604060
]
Grant Ingersoll commented on SOLR-572:
--
{quote}
Would it be hard to check if the query term exists in the dictionary before
returning a suggestion?
{quote}
I'd have to double check, but I think the Lucene SC already does this in some
cases (onlyMorePopular)
> Spell Checker as a Search Component
> ---
>
> Key: SOLR-572
> URL: https://issues.apache.org/jira/browse/SOLR-572
> Project: Solr
> Issue Type: New Feature
> Components: spellchecker
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.3
>
> Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
> SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
> SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
> SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
> SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch
>
>
> Expose the Lucene contrib SpellChecker as a Search Component. Provide the
> following features:
> * Allow creating a spell index on a given field and make it possible to have
> multiple spell indices -- one for each field
> * Give suggestions on a per-field basis
> * Given a multi-word query, give only one consistent suggestion
> * Process the query with the same analyzer specified for the source field and
> process each token separately
> * Allow the user to specify minimum length for a token (optional)
> Consistency criteria for a multi-word query can consist of the following:
> * Preserve the correct words in the original query as it is
> * Never give duplicate words in a suggestion
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604056#action_12604056 ] Oleg Gnatovskiy commented on SOLR-572: -- I think that lower frequency suggestions should be optional. Some users might only want to offer suggestions for misspelled words (words not in the dictionary). Would it be hard to check if the query term exists in the dictionary before returning a suggestion? > Spell Checker as a Search Component > --- > > Key: SOLR-572 > URL: https://issues.apache.org/jira/browse/SOLR-572 > Project: Solr > Issue Type: New Feature > Components: spellchecker >Affects Versions: 1.3 >Reporter: Shalin Shekhar Mangar >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch > > > Expose the Lucene contrib SpellChecker as a Search Component. Provide the > following features: > * Allow creating a spell index on a given field and make it possible to have > multiple spell indices -- one for each field > * Give suggestions on a per-field basis > * Given a multi-word query, give only one consistent suggestion > * Process the query with the same analyzer specified for the source field and > process each token separately > * Allow the user to specify minimum length for a token (optional) > Consistency criteria for a multi-word query can consist of the following: > * Preserve the correct words in the original query as it is > * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[
https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604052#action_12604052
]
Grant Ingersoll commented on SOLR-572:
--
{quote}
I don't think it should give me that suggestion. If a word is in the dictionary
it should not give any suggestions. Am I right?
{quote}
Possibly. I think it should give a better suggestion if one exists (i.e. more
frequent) but otherwise, yes, it shouldn't give any suggestion. For your
example, I would argree that it should not return a suggestion (assuming golf
is in the dictionary). For example, the index could contain the words gilf and
golf, with gilf having a freq. of 1 and golf having a freq of 10. If the
user enters gilf, I think it is reasonable to assume that the suggestion should
be golf, even though gilf exists.
Not saying this is supported yet, or anything, but just laying out the case.
> Spell Checker as a Search Component
> ---
>
> Key: SOLR-572
> URL: https://issues.apache.org/jira/browse/SOLR-572
> Project: Solr
> Issue Type: New Feature
> Components: spellchecker
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.3
>
> Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
> SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
> SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
> SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
> SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch
>
>
> Expose the Lucene contrib SpellChecker as a Search Component. Provide the
> following features:
> * Allow creating a spell index on a given field and make it possible to have
> multiple spell indices -- one for each field
> * Give suggestions on a per-field basis
> * Given a multi-word query, give only one consistent suggestion
> * Process the query with the same analyzer specified for the source field and
> process each token separately
> * Allow the user to specify minimum length for a token (optional)
> Consistency criteria for a multi-word query can consist of the following:
> * Preserve the correct words in the original query as it is
> * Never give duplicate words in a suggestion
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604033#action_12604033 ] Otis Gospodnetic commented on SOLR-236: --- There is so little interest in this patch/functionality now, that I doubt it will get distributed search support in time for 1.3 I would like to commit Bojan's patch for 1.3, though. > Field collapsing > > > Key: SOLR-236 > URL: https://issues.apache.org/jira/browse/SOLR-236 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Emmanuel Keller >Assignee: Otis Gospodnetic > Attachments: field-collapsing-extended-592129.patch, > field_collapsing_1.1.0.patch, field_collapsing_1.3.patch, > field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, > field_collapsing_dsteigerwald.diff, SOLR-236-FieldCollapsing.patch, > SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, solr-236.patch > > > This patch include a new feature called "Field collapsing". > "Used in order to collapse a group of results with similar value for a given > field to a single entry in the result set. Site collapsing is a special case > of this, where all results for a given web site is collapsed into one or two > entries in the result set, typically with an associated "more documents from > this site" link. See also Duplicate detection." > http://www.fastsearch.com/glossary.aspx?m=48&amid=299 > The implementation add 3 new query parameters (SolrParams): > "collapse.field" to choose the field used to group results > "collapse.type" normal (default value) or adjacent > "collapse.max" to select how many continuous results are allowed before > collapsing > TODO (in progress): > - More documentation (on source code) > - Test cases > Two patches: > - "field_collapsing.patch" for current development version > - "field_collapsing_1.1.0.patch" for Solr-1.1.0 > P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solr Maven Artifacts
: This will make it easier for anyone to use solr from within maven. I'll file : a patch to automate whatever can be automated from our ant build so this is : easier for the 1.3 release. : : If people agree that publishing maven artifacts is a good idea, I'll happily : update http://wiki.apache.org/solr/HowToRelease to point to the relevant : information too. automating as much as possible through build.xml targets would definitely help -- i would attach such a patch to SOLR-586, ideally modeled after the way lucene-java does it so there is some "methodology overlap" I'm not sure that i'm really comfortable having 1.2 jars pushed out at this point -- primarily since the POM files wouldn't be included in the source releasees ... it would make it somewhat of a rewriting of history. ...but i won't object if another committer wants to do this. -Hoss
[jira] Updated: (SOLR-589) DisMaxRequestHandler crashes on badly formed query strings ( combinations of "-" and "+" )
[ https://issues.apache.org/jira/browse/SOLR-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-589: --- Attachment: SOLR-589.patch Changed to use non-capturing groups. Also reversed the order the regular expressions are run. Both changes are for performance only. > DisMaxRequestHandler crashes on badly formed query strings ( combinations of > "-" and "+" ) > -- > > Key: SOLR-589 > URL: https://issues.apache.org/jira/browse/SOLR-589 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.2 > Environment: all platforms >Reporter: bram de jong >Priority: Minor > Attachments: SOLR-589.patch, SOLR-589.patch > > > The DisMaxRequestHandler parser crashes on strings which contain double > dashes or various combinations of - and + like: > chocolate cookie - > chocolate -+cookie > chocolate --cookie > chocolate - - cookie > Originally found by me: > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200806.mbox/browser > And verified by Sean Tim: > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200806.mbox/browser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Solr Wiki] Update of "SolrTomcat" by NoblePaul
: Some feedback from the user base. We build Solr from source (to include our : site-specific customisations), and modify the web.xml before it goes into I wouldn't categorize you as a basic user of Solr -- you know java, you write customizations and you build Solr from source. You'd probably consider building Solr from source even if you weren't going to customize it. you sir are not a "Solr User" you are a "Solr Hacker" We have to be aware that there is a large population of Solr users that don't know anything about *writing* java -- nor should they. It's enough that they learn about *running* java (and if they use a freindly servlet container, they don't even need to know that) hence the importance of keeping information about "using solr" and "configuring solr" simple for non-Java speakers. -Hoss
[jira] Commented: (SOLR-579) Extend SimplePost with RecurseDirectories, threads, document encoding , number of docs per commit
[ https://issues.apache.org/jira/browse/SOLR-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603960#action_12603960 ] Hoss Man commented on SOLR-579: --- bq. with a simple perl script this can be converted into solr. shouldn't it be just a easy for that perl script to POST the data to Solr as it is to write it to disk and then use SimplePostTool? > Extend SimplePost with RecurseDirectories, threads, document encoding , > number of docs per commit > - > > Key: SOLR-579 > URL: https://issues.apache.org/jira/browse/SOLR-579 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.3 > Environment: Applies to all platforms >Reporter: Patrick Debois >Priority: Minor > Original Estimate: 72h > Remaining Estimate: 72h > > -When specifying a directory, simplepost should read also the contents of a > directory > New options for the commandline (some only usefull in DATAMODE= files) > -RECURSEDIRS > Recursive read of directories as an option, this is usefull for > directories with a lot of files where the commandline expansion fails and > xargs is too slow > -DOCENCODING (default = system encoding or UTF-8) > For non utf-8 clients , simplepost should include a way to set the > encoding of the documents posted > -THREADSIZE (default =1 ) > For large volume posts, a threading pool makes sense , using JDK 1.5 > Threadpool model > -DOCSPERCOMMIT (default = 1) > Number of documents after which a commit is done, instead of only at > the end > Note: not to break the existing behaviour of the existing SimplePost tool > (post.sh) might be used in scripts -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-589) DisMaxRequestHandler crashes on badly formed query strings ( combinations of "-" and "+" )
[ https://issues.apache.org/jira/browse/SOLR-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-589: --- Attachment: SOLR-589.patch This patch strips out consecutive +/- operators, or dangling +/- operators. > DisMaxRequestHandler crashes on badly formed query strings ( combinations of > "-" and "+" ) > -- > > Key: SOLR-589 > URL: https://issues.apache.org/jira/browse/SOLR-589 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.2 > Environment: all platforms >Reporter: bram de jong >Priority: Minor > Attachments: SOLR-589.patch > > > The DisMaxRequestHandler parser crashes on strings which contain double > dashes or various combinations of - and + like: > chocolate cookie - > chocolate -+cookie > chocolate --cookie > chocolate - - cookie > Originally found by me: > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200806.mbox/browser > And verified by Sean Tim: > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200806.mbox/browser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-493) /admin/file links don't work with legacy configs
[ https://issues.apache.org/jira/browse/SOLR-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603945#action_12603945 ] Hoss Man commented on SOLR-493: --- bq. It also builds the "hidden" list as the inverse of the "gettable" list. would it be simpler/better to add a "gettable" option to ShowFileRequestHandler ? (such that you can use it, or use "hidden" but not both) It didn't really occur to me that ShowFileRequestHandler worked that way until you mentioned it. > /admin/file links don't work with legacy configs > > > Key: SOLR-493 > URL: https://issues.apache.org/jira/browse/SOLR-493 > Project: Solr > Issue Type: Bug > Components: web gui >Reporter: Hoss Man >Assignee: Ryan McKinley >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-493-OldAdminFile.patch > > > admin screen in trunk currently links to /admin/file/?file=schema.xml and > /admin/file/?file=solrconfig.xml by defualt and expects the config to map > /admin/file to ShowFileRequestHandler ... this isn't backwards compatible for > Solr 1.2 users. > we should put some extra logic in SolrCore.init to automaticly register an > instance of ShowFileRequestHandler if there is a section in > solrconfig.xml and no instnces of ShowFileRequestHandler are already > registered (with a warning logged about being deprecated) > http://www.nabble.com/Get-Config---Schema%2C-1.3-dev-Broken--to15360280.html#a15360280 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MoreLikeThisHandler Unit Test
On Jun 10, 2008, at 10:25 AM, Tom Morton wrote: I'm trying to write some unit tests for the MoreLikeThisHandler which test the functionality. I've added documents, committed them, but can't get the query to return a single document from which mlt would get terms. It's as if the documents aren't making it to the index or I'm query them incorrectly. I'm stuck at this point. Can someone take a look at the attached unit tests and let me know if I'm missing something. Thanks...Tom adoc(...) only generates the XML string, but doesn't send it to Solr. Wrap all those adoc() calls with assertU(adoc(...)) and you'll be cooking. Erik
MoreLikeThisHandler Unit Test
I'm trying to write some unit tests for the MoreLikeThisHandler which test
the functionality. I've added documents, committed them, but can't get the
query to return a single document from which mlt would get terms. It's as
if the documents aren't making it to the index or I'm query them
incorrectly. I'm stuck at this point. Can someone take a look at the
attached unit tests and let me know if I'm missing something.
Thanks...Tom
/**
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.solr.handler;
import java.io.IOException;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.Map;
import org.apache.solr.common.params.CommonParams;
import org.apache.solr.common.params.MoreLikeThisParams;
import org.apache.solr.common.params.MultiMapSolrParams;
import org.apache.solr.common.params.SolrParams;
import org.apache.solr.common.util.ContentStream;
import org.apache.solr.common.util.ContentStreamBase;
import org.apache.solr.core.SolrCore;
import org.apache.solr.request.SolrQueryRequestBase;
import org.apache.solr.request.SolrQueryResponse;
import org.apache.solr.search.DocSlice;
import org.apache.solr.util.AbstractSolrTestCase;
/**
* TODO -- this needs to actually test the results/query etc
*/
public class MoreLikeThisHandlerTest extends AbstractSolrTestCase {
@Override public String getSchemaFile() { return "schema.xml"; }
@Override public String getSolrConfigFile() { return "solrconfig.xml"; }
@Override public void setUp() throws Exception {
super.setUp();
lrf = h.getRequestFactory("standard", 0, 20 );
}
public void testInterface()
{
SolrCore core = h.getCore();
MoreLikeThisHandler mlt = new MoreLikeThisHandler();
Map params = new HashMap();
MultiMapSolrParams mmparams = new MultiMapSolrParams( params );
SolrQueryRequestBase req = new SolrQueryRequestBase( core,
(SolrParams)mmparams ) {};
// requires 'q' or single content stream
try {
mlt.handleRequestBody( req, new SolrQueryResponse() );
}
catch( Exception ex ) {} // expected
// requires 'q' or single content stream
try {
ArrayList streams = new ArrayList( 2 );
streams.add( new ContentStreamBase.StringStream( "hello" ) );
streams.add( new ContentStreamBase.StringStream( "there" ) );
req.setContentStreams( streams );
mlt.handleRequestBody( req, new SolrQueryResponse() );
}
catch( Exception ex ) {} // expected
adoc(new String[]{"id","42","name","Tom Cruise","subword","Top
Gun","subword","Risky Business","subword","The Color of
Money","subword","Minority Report","subword", "Days of Thunder","subword",
"Eyes Wide Shut","subword", "Far and Away"});
adoc(new String[]{"id","43","name","Tom Hanks","subword","The Green
Mile","subword","Forest Gump","subword","Philadelphia
Story","subword","Big","subword","Cast Away"});
adoc(new String[]{"id","44","name","Harrison Ford","subword","Star
Wars","subword","Indiana Jones","subword","Patriot Games","subword","Regarding
Henry"});
adoc(new String[]{"id","45","name","George Harrison","subword","Yellow
Submarine","subword","Help","subword","Magical Mystery Tour","subword","Sgt.
Peppers Lonley Hearts Club Band"});
adoc(new String[]{"id","46","name","Nicole
Kidman","subword","Batman","subword","Days of Thunder","subword","Eyes Wide
Shut","subword","Far and Away"});
commit();
params.put(CommonParams.Q, new String[]{"id:42"});
params.put(MoreLikeThisParams.SIMILARITY_FIELDS, new
String[]{"name,subword"});
params.put(MoreLikeThisParams.INTERESTING_TERMS,new String[]{"details"});
params.put(MoreLikeThisParams.MIN_TERM_FREQ,new String[]{"1"});
params.put(MoreLikeThisParams.MIN_DOC_FREQ,new String[]{"1"});
params.put(MoreLikeThisParams.MAX_QUERY_TERMS,new String[]{"5"});
params.put(MoreLikeThisParams.MATCH_INCLUDE,new String[]{"true"});
try {
SolrQueryResponse rsp = new SolrQueryResponse();
mlt.handleRequestBody(req, rsp);
String response = (String) rsp.getValues().get("response");
this.assertNotNull(response);
} catch (Exception e) {
e.printStackTrace();
}
}
}
