The wordforms were working I just forgot to remove it from the search 
params. Thanks for pointing it out though so I can clean that part out.

Zip code is a varchar which is why I passed the type as integer in the 
index since float was giving me a error.

  has created_at, updated_at 
>   has(:id, :as => :user_id)
>   has(:zip_code, :as => :zip_code, :type => :integer)
>   set_property :wordforms => 'lib/word.txt'


On Friday, August 22, 2014 11:55:15 PM UTC-4, Pat Allan wrote:
>
> Hi Alexa
>
> Can you share your index definition? And what data type is the zip_code 
> column?
>
> Also:
> * wordforms is an option only for config/thinking_sphinx.yml (under each 
> environment) or via `set_property` in an index definition. You can’t 
> specify wordforms on a per-search basis.
> * If you’re using Thinking Sphinx v3, extended is the only match mode 
> possible, so there’s no need to specify it when querying.
>
> Cheers
>
> — 
> Pat
>
> On 23 Aug 2014, at 2:26 am, alexa <[email protected] <javascript:>> 
> wrote:
>
> For your second option. I have the code setup but it is doing the reverse. 
> It's starting at "keyword" AND or zip_code. When it should be how you 
> explained "zip code" AND or keywords.
>
> User.search(params[:search].gsub(/\s+/, ' | '), :with => {:zip_code => 
> current_user.zip_code}, :wordforms => 'lib/word.txt', :match_mode => 
> :extended, :without => {:user_id => current_user.id})
>
> Do I have it setup in the wrong place?
>
>
>
>
> On Thursday, August 21, 2014 3:39:00 PM UTC-4, alexa wrote:
>>
>> Thanks for the response.
>>
>> I reviewed my post and realized I didn't include any code.
>>
>> From the docs the only related information I found was using the with and 
>> without method. I tried both prior to the original posting:
>>
>> @users = User.search(params[:search].gsub(/\s+/, ' | '), :wordforms => 
>> 'lib/word.txt', :match_mode => :extended, :with_all => {:zip_code => 
>> current_user.zip_code})            
>>
>> In the model:
>>
>>   has(:zip_code, :as => :user_zip_code)
>>
>> Reviewing your response I believe the second option would be the best 
>> route given my setup. 
>>
>> On Wednesday, August 20, 2014 11:00:33 PM UTC-4, Pat Allan wrote:
>>>
>>> Hi Alexa
>>>
>>> If you can remove the NY/10001 keywords from the query, and instead use 
>>> that for calculating location/distance with the geodist functionality, then 
>>> that should allow you to get the results you want.
>>>
>>> Or, you could keep it all in the query, but change the logic to be 10001 
>>> AND (guitar OR stereo) - which in Sphinx’s terms is “10001 (guitar | 
>>> stereo)”.
>>>
>>> Are either of these options feasible?
>>>
>>> — 
>>> Pat
>>>
>>> On 21 Aug 2014, at 5:48 am, alexa wilson <[email protected]> wrote:
>>>
>>> I was looking through the docs and I couldn't find the answer I was 
>>> seeking. Perhaps someone here can point me in the right direction.
>>>
>>> I am going to setup so when a user performs a search it will include 
>>> their location by default. What I couldn't find in the docs is how can a 
>>> multiple search query be done from within the users distance?
>>>
>>> The search presently functions that I can do multiple search query, ex: 
>>> 10001, guitar, stereo. The results will show matches from 1 of the 3 
>>> keywords. So it will show all things related to 10001, all things related 
>>> to guitar, and all things related to stereo.
>>>
>>> I would like for it to show results from within the specify distance 
>>> (set by default in the controller) for the "guitar" and "stereo" keyword. 
>>> Thus meaning, the default method will pull the "guitar" and "stereo" 
>>> listings from any distance. Instead it should pull "guitar" and "stereo" 
>>> listings that are within distance to the "10001" location only.
>>>
>>> This way a user can search the state of New York for guitars and or 
>>> stereos, as oppose to pulling all NY related searches, all guitar searches, 
>>> and all stereo searches which would essentially be returning results from 
>>> all 50 states.
>>>
>>> Is this possible to do?
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Thinking Sphinx" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/thinking-sphinx.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Thinking Sphinx" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] <javascript:>.
> To post to this group, send email to [email protected] 
> <javascript:>.
> Visit this group at http://groups.google.com/group/thinking-sphinx.
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Thinking Sphinx" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/thinking-sphinx.
For more options, visit https://groups.google.com/d/optout.

Reply via email to