I've got SOLR up and running, indexing data via the DIH, and properly returning results for queries. I'm trying to setup another core to run suggester, in order to autocomplete geographical locations. We have a web application that needs to take a city, state / region, country input. We'd like to do this in a single entry box. Here are some examples:
Brooklyn, New York, United States of America
Philadelphia, Pennsylvania, United States of America
Barcelona, Catalunya, Spain
Assume for now that every location around the world can be split into this 3-form input. I've setup my DIH to create a TemplateTransformer field that combines the 4 tables (city, state and country are all independent tables connected to each other by a master places table) into a field called "fullplacename":
<field column="fullplacename" template="${city_join.plainname},
${region_join.plainname}, ${country_join.plainname}"/>
I've defined a "text_auto" field in schema.xml:
<fieldType class="solr.TextField" name="text_auto">
<analyzer>
<tokenizer class="solr.KeywordTokenizerFactory"/>
<filter class="solr.LowerCaseFilterFactory"/>
</analyzer>
</fieldType>
and have defined these two fields as well:
<field name="name_autocomplete" type="text_auto" indexed="true" stored="true" multiValued="true" />
<copyField source="fullplacename" dest="name_autocomplete" />
Now, here's my problem. This works fine for the first term, i.e. if I type "brooklyn" I get the results I'd expect, using this URL to query:
http://localhost:8983/solr/places/suggest?q=brooklyn
However, as soon as I put a comma and/or a space in there, it breaks them up into 2 suggestions, and I get a suggestion for each:
http://localhost:8983/solr/places/suggest?q=brooklyn%2C%20ny
Gives me a suggestion for "brooklyn" and a suggestion for "ny" instead of a suggestion that matches "brooklyn, ny". I've tried every solution I can find via google and haven't had any luck. Is there something simple that I've missed, or is this the wrong approach?
Thanks!
EDIT: Just in case, here's the searchComponent and requestHandler definition:
<requestHandler name="/suggest" class="org.apache.solr.handler.component.SearchHandler">
<lst name="defaults">
<str name="spellcheck">true</str>
<str name="spellcheck.dictionary">suggest</str>
<str name="spellcheck.count">10</str>
</lst>
<arr name="components">
<str>suggest</str>
</arr>
</requestHandler>
<searchComponent name="suggest" class="solr.SpellCheckComponent">
<lst name="spellchecker">
<str name="name">suggest</str>
<str name="classname">org.apache.solr.spelling.suggest.Suggester</str>
<str name="lookupImpl">org.apache.solr.spelling.suggest.tst.TSTLookup</str>
<str name="field">name_autocomplete</str>`<br/>
</lst>
</searchComponent>
The problem lies in the suggester. Like the spellchecker it tokenizes on whitespace.
http://lucene.472066.n3.nabble.com/suggester-issues-tp3262718p3266140.html has a solution for this problem.
You are using the KeywordTokenizer which will not create separate tokens for "Brooklyn", "NY" and "United States".
Your example queries do not look so much like autocomplete but more like regular searches.
Autocomplete query (IMHO) contains only partial terms:
http://localhost:8983/solr/places/suggest?q=brook
for type ahead lists. You want to use EdgeNGram for that: http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.EdgeNGramFilterFactory
Most probably in combintation with StandardTokenizer and/or WordDelimiterFilterFactory.
For your query example:
http://localhost:8983/solr/places/suggest?q=brooklyn%2C%20ny
StandardTokenizer in combination with LowercaseFilter and dismax request handler with a good configuration of the mm parameter - restricting hits to those that contain all input terms - would work well, see: http://wiki.apache.org/solr/DisMaxQParserPlugin#mm_.28Minimum_.27Should.27_Match.29
I feel the accepted answer is a bit too complex. An elegant way of doing it would be to use http://localhost:8983/solr/places/suggest?spellcheck.q=brooklyn in place of http://localhost:8983/solr/places/suggest?q=brooklyn. As mentioned here
Related
Short version:
Does anyone knows if something happened with EdgeNGramFilterFactory for solr5? It used to work fine on solr 4, but I just upgraded to solr5 and the cores having this fields using this filter refuses to load ...
Long story:
This configuration used to work in solr4.10 (schema.xml):
<field name="NAME" type="string" indexed="true" stored="true" required="true" multiValued="false"/>
<field name="PP" type="text_prefix" indexed="true" stored="false" required="false" multiValued="false"/>
<copyField source="NAME" dest="PP">
<fieldType name="text_prefix" class="solr.TextField" positionIncrementGap="100">
<analyzer type="index">
<tokenizer class="solr.KeywordTokenizerFactory"/>
<filter class="solr.EdgeNGramFilterFactory" minGramSize="2" maxGramSize="15" side="front"/>
</analyzer>
<analyzer type="query">
<tokenizer class="solr.KeywordTokenizerFactory"/>
</analyzer>
</fieldType>
And the documentation says I did it right (no clear mention if it is for solr4 or solr5).
However, when I am trying to add a collection using this configuration, it fails with the following message:
<lst name="failure">
<str>
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error from server at http://localhost:8983/solr: Error CREATEing SolrCore 'test_collection': Unable to create core [test_collection] Caused by: Unknown parameters: {side=front}</str>
</lst>
I removed the side=front "unknown" parameter, started from scratch and it worked - meaning no more errors.
So, while it used to work for solr4 without any additional change, for solr5 it no longer works. Did something changed? Did I miss any doc regarding this filter? Any extra library I need to load to make this work?
And final, if the above is meant to be like this (bug/feature/whatever) - is there any workaround in order to have this "side-substring" indexing-functionality without me having to generate the values when I am adding docs to solr?
Update: with the "hacked" schema (i.e. without side=front), I indexed the documents and changed the PP field to be stored. when I searched, it looks like it indexes the entire value. For example, for NAME:ELEPHANT, I found PP:ELEPHANT ...
That attribute side has been removed in the context of LUCENE-3907 in Version 4.4. This filter now always behaves as if you gave in side="front". So you may just remove that attribute and are fine, since you are using it the "front-way".
As you can read in the conversation of the linked Lucene Issue
If you need reverse n-grams, you could always add a filter to do that
afterwards. There is no need to have this as separate logic in this
filter. We should split logic and keep filters as simple as possible.
And this is what has been done. The side attribute has been removed from the filter.
This has been done in Lucene, not directly in Solr. As Lucene is a Java-API it has been mentioned in the Java Doc of the filter
As of Lucene 4.4, this filter does not support
EdgeNGramTokenFilter.Side.BACK (you can use ReverseStringFilter
up-front and afterward to get the same behavior), handles
supplementary characters correctly and does not update offsets
anymore.
This may be the reason why you do not find a word about it in the Solr documentation. But this change has also been mentioned in Lucene's Change Log.
in solr query search,
a search
q=*%3A*&fq=grand_cat_str%3ABeklædning
Solr will read the fq as:<str name="fq">grand_cat_str:Beklædning</str>
and return no result. Doing wild search for Bekl*dning would return correct result.
[edit]
I added
<fieldType name="string" class="solr.StrField" sortMissingLast="true" >
<analyzer type="index">
<tokenizer class="solr.StandardTokenizerFactory"/>
<filter class="solr.ASCIIFoldingFilterFactory"/>
</analyzer>
</fieldType>
but got a error:
<org.apache.solr.common.SolrException: FieldType: StrField (string) does not support specifying an analyzer
This is related to how Solr handles characters that are not in the first 127 ASCII character set. The best recommendation is add the ASCIIFoldingFilterFactory analyzer to your field grand_cat_str in your schema.
Please reference Specifying an Analyzer in the Schema if you need guidance on adding a analyzer.
If most documents in his corpus are in that same language (Dannish?) then it is very possible that applying ASCIIFoldingFilterFactory is a bad option, depends on how the users are expected to enter their queries.
Have you tried just encoding the query??
q=*%3A*&fq=grand_cat_str%3ABekl%C3%A6dning
should work just fine
it is indeed an escape problem.
using org.apache.solr.client.solrj.util.ClientUtils.escapeQueryChars(String)
is able to make string readble.
Current Features:
Autocomplete using solr terms component, parameter terms.prefix.
bounding box for geo location searches.
Things Tried:
I have tried to combine both queries into one. However I never get the results to filter by geo location.
Rather I get everything from the terms.prefix search.
I have also tried using dismax, edismax + bbox geo location search. I know that dismax wouldn't work because it doesn't have a prefix parameter.
I looked day and night on Google try to figure this out.
I would hate to stem on my field name "names", so that every letter gets considered a keyword.
Any help is really appreciated.
Unfortunately you cannot do this in the termscomponent as it simply does not support filtering based on other fields than the one that you are issuing the terms component on.
The simplest solution to the problem is to use the standard requesthandler (ie <requestHandler name="standard" class="solr.SearchHandler>) with your bounding box filter:
fq={!bbox}&sfield=store&pt=45.15,-93.85&d=5
and a facet on the field that you want to list terms for (assuming your field name is 'names'):
facet=true&facet.field=names&f.names.facet.prefix=$yourprefix$
you will end up with a query like:
/select?q=*:*&fq={!bbox}&sfield=store&pt=45.15,-93.85&d=5&facet=true&facet.field=names&f.names.facet.prefix=$yourprefix$
giving a result like:
<lst name="facet_counts">
<lst name="facet_queries"/>
<lst name="facet_fields">
<lst name="name">
<int name="maxtor">1</int>
<int name="memory">1</int>
<int name="mobile">1</int>
<int name="mp500">1</int>
<int name="mb">0</int>
<int name="mini">0</int>
</lst>
</lst>
</lst>
(in the facet section)
Im making a group table that is populated from an XML/RSS feed, ive managed to parse the data to the table just fine, but im stuck on how to make the table grouped?
ie, i want an events listing, and i want to organise the events in groups, using the Month for each group, how would i achieve this?
below is my XML structure, its pretty basic
<EventsUpcoming>
<Event id="1">
<month>July</month>
<title>Ian Moss</title>
<date>Saturday, July 1st</date>
<ticket>$35 On the door</ticket>
<description>
Ian Moss from Cold Chisel fame will be touring Australia and the only venue to secure him in Perth is the Blvd.
</description>
</Event>
<Event id="2">
<month>August</month>
<title>Cold Chisel</title>
<date>Saturday, August 3rd</date>
<ticket>$25 on the door</ticket>
<description>
From Khe San fame, Cold Chisel is back with the legendary Jimmy Barnes, dont miss out this gig. Its gonna go down in the books for sure!
</description>
</Event>
<Event id="3">
<month>September</month>
<title>Australian Crawl</title>
<date>Saturday, September 1st</date>
<ticket>Free</ticket>
<description>
They're one of Australia's most iconic band names, be sure to come down and check them out before they die.
</description>
</Event>
</EventsUpcoming>
If anyone knows any tutorial sites that might be helpful or just tips on how to go about doing this, thatd be much appreciated. Thanks in advance :)
NSMutableSet doesn't store the duplicate values,it only stores distinct ones.So at the time of parsing,you can use NSMutableSet to store the 'month' value of each xml element and set the number of sections in a tableview to the count of your NSMutableSet.
I am developing an application for iPhone and one part of it deals with a list of currencies and daily exchange rates. I am using SQLite to store all these rates.
Now I came to the part where I want to make the update part of my database with the new exchange rates.
The first thought was make a request to a server with a specific date and to read back an XML containing something like:
<date value="2010-10-04">
<currency name="EUR" rate="xxx" />
<currency name="USD" rate="yyy" />
<currency name="GBP" rate="zzz" />
........
</date>
<date value="2010-10-05">
<currency name="EUR" rate="xxx" />
<currency name="USD" rate="yyy" />
<currency name="GBP" rate="zzz" />
........
</date>
But now I was thinking isn't it better to make my own format, something like:
#|2010-10-04#EURxxx#USDyyy#GBPzzz#|2010-10-05#EURxxx#USDyyy#GBPzzz##
The separator will be #. Known that always the date takes 11 characters and starts with | and currency code takes 3 characters, I can search the rate until I will find a # sign.
Because I want to send as little data as I can I think this second approach will be better than the usual XML, even if I reduce the XML to:
<d v="2010-10-04">
<c name="EUR" r="xxx" />
<c name="USD" r="yyy" />
<c name="GBP" r="zzz" />
........
</d>
<d v="2010-10-05">
<c name="EUR" r="xxx" />
<c name="USD" r="yyy" />
<c name="GBP" r="zzz" />
........
</d>
What are your pro & cons for this?
XML is easier to read and parse. Unless you're fetching a zillion currencies and daily rates a day, the # of bytes shouldn't be an issue.
JSON format would split the difference between a proprietary format and a standard format. It is somewhat less verbose than XML and has the flexibility and maintainability vodkhang rightly expects.
The pros:
As you already stated, it is shorter, faster to retrieve.
Faster to parse as well
The cons:
If you develop the server side and the other developer on the mobile side, then he may get confused when there are no meanings
It is hard to scale when you have more and more attributes and if you delete or change some attributes, you have to go over all codes to change it.
CFPropertyList is pretty good if you're using PHP as your server-side language.
Easy to integrate with your server code and has built in support in iOS (e.g. an NSDictionary can be created directly from a plist file).
Link: http://code.google.com/p/cfpropertylist/