Re: CountComponent
Anon SVN http://svn.tailsweep.com/opensource/solr-contrib/ Cheers //Marcus On Wed, Mar 10, 2010 at 10:24 AM, Marcus Herou marcus.he...@tailsweep.comwrote: Filed it here. https://issues.apache.org/jira/browse/SOLR-1814 Did not change prio from major since that I guess is up to the community. Cheers /Marcus On Tue, Mar 9, 2010 at 7:48 PM, Steven A Rowe sar...@syr.edu wrote: Hi Marcus, http://wiki.apache.org/solr/HowToContribute Or were you asking a different question? Steve On 03/09/2010 at 10:52 AM, Marcus Herou wrote: Hi. I've developed a SearchComponent named CountComponent which emulates the SQL equiv select count(distinct field)... I think that it perhaps should be put in contrib or such. How can I get this piece of code into Solr ? Cheers //Marcus Herou -- Marcus Herou CTO and co-founder Tailsweep AB +46702561312 marcus.he...@tailsweep.com http://www.tailsweep.com/ -- Marcus Herou CTO and co-founder Tailsweep AB +46702561312 marcus.he...@tailsweep.com http://www.tailsweep.com/ -- Marcus Herou CTO and co-founder Tailsweep AB +46702561312 marcus.he...@tailsweep.com http://www.tailsweep.com/
[jira] Updated: (SOLR-1703) Sorting by function problems on multicore (more than one core)
[
https://issues.apache.org/jira/browse/SOLR-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-1703:
-
Description:
When using sort by function (for example dist function) with multicore with
more than one core (on multicore with one core, ie. the example deployment the
problem doesn`t exist) there is a problem with not using the right schema. I
think there is a problem with this portion of code:
QueryParsing.java:
{code}
public static FunctionQuery parseFunction(String func, IndexSchema schema)
throws ParseException {
SolrCore core = SolrCore.getSolrCore();
return (FunctionQuery) (QParser.getParser(func, func, new
LocalSolrQueryRequest(core, new HashMap())).parse());
// return new FunctionQuery(parseValSource(new StrParser(func), schema));
}
{code}
Code above uses deprecated method to get the core sometimes getting the wrong
core effecting in impossibility to find the right fields in index.
was:
When using sort by function (for example dist function) with multicore with
more than one core (on multicore with one core, ie. the example deployment the
problem doesn`t exist) there is a problem with not using the right schema. I
think there is a problem with this portion of code:
QueryParsing.java:
public static FunctionQuery parseFunction(String func, IndexSchema schema)
throws ParseException {
SolrCore core = SolrCore.getSolrCore();
return (FunctionQuery) (QParser.getParser(func, func, new
LocalSolrQueryRequest(core, new HashMap())).parse());
// return new FunctionQuery(parseValSource(new StrParser(func), schema));
}
Code above uses deprecated method to get the core sometimes getting the wrong
core effecting in impossibility to find the right fields in index.
Sorting by function problems on multicore (more than one core)
--
Key: SOLR-1703
URL: https://issues.apache.org/jira/browse/SOLR-1703
Project: Solr
Issue Type: Bug
Components: multicore, search
Affects Versions: 1.5
Environment: Linux (debian, ubuntu), 64bits
Reporter: Rafał Kuć
When using sort by function (for example dist function) with multicore with
more than one core (on multicore with one core, ie. the example deployment
the problem doesn`t exist) there is a problem with not using the right
schema. I think there is a problem with this portion of code:
QueryParsing.java:
{code}
public static FunctionQuery parseFunction(String func, IndexSchema schema)
throws ParseException {
SolrCore core = SolrCore.getSolrCore();
return (FunctionQuery) (QParser.getParser(func, func, new
LocalSolrQueryRequest(core, new HashMap())).parse());
// return new FunctionQuery(parseValSource(new StrParser(func), schema));
}
{code}
Code above uses deprecated method to get the core sometimes getting the wrong
core effecting in impossibility to find the right fields in index.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1316) Create autosuggest component
[ https://issues.apache.org/jira/browse/SOLR-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12844083#action_12844083 ] Grant Ingersoll commented on SOLR-1316: --- What's the status on this? Create autosuggest component Key: SOLR-1316 URL: https://issues.apache.org/jira/browse/SOLR-1316 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.4 Reporter: Jason Rutherglen Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 1.5 Attachments: suggest.patch, suggest.patch, suggest.patch, TST.zip Original Estimate: 96h Remaining Estimate: 96h Autosuggest is a common search function that can be integrated into Solr as a SearchComponent. Our first implementation will use the TernaryTree found in Lucene contrib. * Enable creation of the dictionary from the index or via Solr's RPC mechanism * What types of parameters and settings are desirable? * Hopefully in the future we can include user click through rates to boost those terms/phrases higher -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1743) error reporting is rendering 404 missing core name in path for all type of errors
[ https://issues.apache.org/jira/browse/SOLR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-1743: --- Attachment: SOLR-1743.restore14behavior.patch Ok, I've been doing some more testing... First off: a lot of my early comments on this issue were inaccurate -- in some cases I was trying to test the behavior of trunk using a single core example with some errors in the solrconfig.xml, but i was using the example/solr dir on the trunk, and i completly forgot that it has a solr.xml file in it now. From what i can tell, the only real difference between the behavior of trunk, and the behavior of Solr 1.4 is that: in 1.4 when using legacy single core mode (ie: no solr.xml) you would get good error messages if an low level error happened that completely prevented the core from loading (ie: schema init problem, or xml parsing problem with solrconfig.xml) This is because the default behavior of abortOnConfigurationError was true for legacy single core mode, and that boolean drives SolrDispatchFilter's decision about what type of error message to display. The latest attached patch (SOLR-1743.restore14behavior.patch) should get us back to the error reporting behavior of Solr 1.4 -- i think we should go ahead and commit this to the trunk as a temporary fix for the current bug, while we flesh out improvements to the entire concept of abortOnConfigurationError in another issue. error reporting is rendering 404 missing core name in path for all type of errors --- Key: SOLR-1743 URL: https://issues.apache.org/jira/browse/SOLR-1743 Project: Solr Issue Type: Bug Components: Build Environment: all Reporter: Marcin Assignee: Mark Miller Fix For: 1.5 Attachments: SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.restore14behavior.patch despite the error in schema syntax or any other type of error you will always get: 404 missing core name in path communicate. cheers, /Marcin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Abstractify FacetComponent and SimpleFacets
I would like to utilize all code that has been written around Facets and just to hook in somewhere SimpleFacets.getFacetDateCounts calls rangeCount i.e. I would like to group on date but return something else than a count in this case the sum of another field than the actual faceted field but I feel that the generic way would be to be able to hook in a FunctionQuery somehow there. So what I try to say instead of ctrl-c those two classes I would like to refactor it somehow so I can use a template pattern or such here. Should I write the patch and would it be accepted by the community if it is written good ? Cheers //Marcus -- Marcus Herou CTO and co-founder Tailsweep AB +46702561312 marcus.he...@tailsweep.com http://www.tailsweep.com/
[jira] Commented: (SOLR-1743) error reporting is rendering 404 missing core name in path for all type of errors
[ https://issues.apache.org/jira/browse/SOLR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12844227#action_12844227 ] Mark Miller commented on SOLR-1743: --- This looks good to me as a first step - tested with both config and schema errors. Would be nice if single core with the solr.xml also worked, but no biggie - we can fix with the rest of multi-core. bq. Note for no good reason what so ever, Well, I think it was supposed to work (even though the whole idea is kind of broken anway), cause it attempted to, so reason is prob a bug ... error reporting is rendering 404 missing core name in path for all type of errors --- Key: SOLR-1743 URL: https://issues.apache.org/jira/browse/SOLR-1743 Project: Solr Issue Type: Bug Components: Build Environment: all Reporter: Marcin Assignee: Mark Miller Fix For: 1.5 Attachments: SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.restore14behavior.patch despite the error in schema syntax or any other type of error you will always get: 404 missing core name in path communicate. cheers, /Marcin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Abstractify FacetComponent and SimpleFacets
I have now implemented Facet with FunctionQueries it is really cool! Sorry but even though the author of SimpleFacets (Yonik) says in the javadoc that one should subclass it to leverage more functionality I did not really find that very true in this case. Too much code that not could be templatified easily. So... I crtl-c'd it... = very bad by me. I have added very few quite trivial lines of code that should be generic enough to be put into Solr core or into contrib after some basic tweaking by a committer perhaps. Added two new features. 1. facet.innerFunction (support for all SOLR function queries) extracts the ValueSource from the parsed FunctionQuery and foreach doc in the faceted range search result returns the double value for that query and passes it on to the outerFunction 2. facet.outerFunction - proprietary function support, currently only sum avg (before I implement the whole java.lang.Math package I need to verify that it is not done before and in a much better way, probably function chaining is needed as well i.e. product(a, sum(b,c)) ) Very trivial - just collects the innerFunction retvals and for instance sums them or average them. The result of this method is returned instead of the default counting of docs as per default in the previous SimpleFacets (which I ctrl-c'd into FunctionFacets Example: GET http://127.0.0.1:8110/solr/blogosphere-sv-2010Q1/select?q=*:*rows=0indent=onfacet=truefacet.date=publishedDatefacet.date.start=NOW/DAY-30DAYSfacet.date.end=NOW/DAY%2B1DAYfacet.date.gap=%2B1DAY; *facet.outerFunction=sumfacet.innerFunction=blogRank* Can be found here http://svn.tailsweep.com/opensource/solr-contrib/trunk/src/main/java/org/apache/solr/handler/component/ Cheers //Marcus On Thu, Mar 11, 2010 at 9:23 PM, Marcus Herou marcus.he...@tailsweep.comwrote: I would like to utilize all code that has been written around Facets and just to hook in somewhere SimpleFacets.getFacetDateCounts calls rangeCount i.e. I would like to group on date but return something else than a count in this case the sum of another field than the actual faceted field but I feel that the generic way would be to be able to hook in a FunctionQuery somehow there. So what I try to say instead of ctrl-c those two classes I would like to refactor it somehow so I can use a template pattern or such here. Should I write the patch and would it be accepted by the community if it is written good ? Cheers //Marcus -- Marcus Herou CTO and co-founder Tailsweep AB +46702561312 marcus.he...@tailsweep.com http://www.tailsweep.com/ -- Marcus Herou CTO and co-founder Tailsweep AB +46702561312 marcus.he...@tailsweep.com http://www.tailsweep.com/
Re: Abstractify FacetComponent and SimpleFacets
Interesting looking stuff Marcus! Seems sort of related to stat.facet (calc stats on unique facet values) http://wiki.apache.org/solr/StatsComponent On Thu, Mar 11, 2010 at 5:49 PM, Marcus Herou marcus.he...@tailsweep.com wrote: I have now implemented Facet with FunctionQueries it is really cool! Sorry but even though the author of SimpleFacets (Yonik) says in the javadoc that one should subclass it to leverage more functionality I did not really find that very true in this case. Hoss was actually the first author of SimpleFacets - SOLR-44 (Solr didn't even have built-in faceting when it came into the incubator!) -Yonik http://www.lucidimagination.com
Re: Abstractify FacetComponent and SimpleFacets
On Mar 11, 2010, at 6:30 PM, Yonik Seeley wrote: Interesting looking stuff Marcus! Seems sort of related to stat.facet (calc stats on unique facet values) http://wiki.apache.org/solr/StatsComponent And https://issues.apache.org/jira/browse/SOLR-1622 On Thu, Mar 11, 2010 at 5:49 PM, Marcus Herou marcus.he...@tailsweep.com wrote: I have now implemented Facet with FunctionQueries it is really cool! Sorry but even though the author of SimpleFacets (Yonik) says in the javadoc that one should subclass it to leverage more functionality I did not really find that very true in this case. Hoss was actually the first author of SimpleFacets - SOLR-44 (Solr didn't even have built-in faceting when it came into the incubator!) -Yonik http://www.lucidimagination.com
local solr geo_distance
Hi I'm getting geo_distance as str eventhough I'm define the field as tdouble. my search looks like /solr/select?qt=geolat=xx.xxlong=yy.yyq=*radius=10 Is there anyway i can get is as double instead of str -- View this message in context: http://old.nabble.com/local-solr-geo_distance-tp27873821p27873821.html Sent from the Solr - Dev mailing list archive at Nabble.com.
