That's exactly what I use :)

So my guess was correct? And you think this will not doubling (overheading) 
DB requests?

Thanks!

On Thursday, 29 January 2015 10:19:51 UTC-3, Pat Allan wrote:
>
> You can use search_for_ids instead of search - that’ll avoid instantiating 
> all of your Item objects via TS :)
>
> On 29 Jan 2015, at 11:44 pm, Misha Slyusarev <[email protected] 
> <javascript:>> wrote:
>
> Great thinking! That's probably what I can do if my idea won't work.
>
> So yesterday I decided stop requesting TS for all records, but instead get 
> all item IDs (using  *per_page: 1000*) and then do another request to the 
> DB with left join and all required sorting. So this works. And according to 
> documentation a thousand of records is the maximum TS will return anyway. 
> What I'm concerning about is obviously performance.
>
> So my guess is that TS will anyway do the same thing, that is, it will 
> firstly find all the IDs and secondly look for real data in the DB. Is it 
> true? And what do you think generally about this approach?
>
> Thanks!
> Misha
>
> On Wednesday, 28 January 2015 19:43:02 UTC-3, Pat Allan wrote:
>>
>> I’ve had to do something like this for clients in the past… but it’s 
>> never particularly neat.
>>
>> What you can do is add an attribute to your Item index indicating how 
>> many variations it has:
>>
>>     join item_variations # if you’re not using the association already in 
>> the index
>>     has “COUNT(item_variations.id)”, :as => :variations_count, :type => 
>> :integer
>>
>> Also, add an attribute of the same name to your ItemVariation index:
>>
>>     has “0”, :as => :variations_count, :type => :integer
>>
>> And then, search across both models, but filter out items which have 
>> variations:
>>
>>     ThinkingSphinx.search params[:q],
>>       :models => [Item, ItemVariation],
>>       :with => {:variations_count => 0}
>>
>> Of course, then you’re getting a mixture of records back from Sphinx, so 
>> your views/controllers will need to manage that situation accordingly.
>>
>> — 
>> Pat
>>
>> On 29 Jan 2015, at 1:38 am, Misha Slyusarev <[email protected]> wrote:
>>
>> Yeah, I thought about that. The problem is that not all items have 
>> variations. :( :( :(
>>
>> Also I came up with *join *instruction for index which give me actually 
>> what I wanted -- left join on item_variations. But I can't figure out how 
>> to 
>> - select fields that connected to the variation, like 
>> items_found[0].variaiton_id
>> - make TS not add GROUP by item ID, so I could have a few records with 
>> the same item ID but different variations IDs.
>>
>> Any thoughts I can do it somehow?
>>
>> Thanks!
>>
>> On Wednesday, 28 January 2015 10:23:16 UTC-3, Pat Allan wrote:
>>>
>>> Hi Misha
>>>
>>> In this case I think you want to be searching on ItemVariation instead 
>>> of Item - you’re asking Sphinx to return an Item more than once, and it 
>>> doesn’t have the ability to do that. Having an index on ItemVariation 
>>> (pulling in Item details in fields and attributes as needed) is almost 
>>> certainly going to be a better fit.
>>>
>>> Cheers
>>>
>>> — 
>>> Pat
>>>
>>> On 28 Jan 2015, at 3:03 am, Misha Slyusarev <[email protected]> wrote:
>>>
>>> Hi Pat!
>>> Thank you for all your help so far! The problem is still actual though.
>>>
>>> So basically what I want to get is an array where each of the elements 
>>> includes information from both Item and ItemVariation models (Item has_many 
>>> ItemVariations). Generally I can achieve this in ActiveRecord using *left 
>>> join*, but in ThinkingSphinx when I try to use same technic (as shown 
>>> bellow with *joins: 'left join..'*) I fail since I get only first 
>>> variation (first element of the joined table) along with Item.
>>>
>>> The idea behind that is to display variations alongside with items on 
>>> the list. And to be able to treat them independently.
>>>
>>> Here is the query
>>>
>>> *items_found = Item.search params[:q], *
>>> *    :joins => 'left join item_variations iv on iv.item_id=items.id 
>>> <http://items.id/>',*
>>> *    :select => 'items.*, iv.id <http://iv.id/> as variation_id'*
>>>
>>>
>>> So bellow is what I'm getting
>>>
>>> *items_found[0]:*
>>> *  id: 1*
>>> *  variation_id: 3434*
>>>
>>> *items_found[1]:*
>>> *  id: 2*
>>> *  variation_id: nil*
>>>
>>>
>>> And here is what I want to get (here Item 1 goes with two variations and 
>>> they come as standalone elements of the array, and both have same item's 
>>> information, but different item variation's information)
>>>
>>>
>>> items_found[0]:
>>>   id: 1
>>>   variation_id: 3434
>>>
>>> items_found[1]:
>>>   id: 1
>>>   variation_id: 9898
>>>
>>> items_found[2]:
>>>   id: 2
>>>   variation_id: nil
>>>
>>>
>>> Please keep in mind that I use TS v2.0.10
>>>
>>> Appreciate any advise or thoughts!
>>> Misha
>>>
>>> On Monday, 10 November 2014 08:05:26 UTC-3, Pat Allan wrote:
>>>>
>>>> Hi Misha
>>>>
>>>> Sphinx always paginates - there’s no way to turn that off. You can 
>>>> request really large pages though (the default maximum is 1000 records, 
>>>> but 
>>>> that can be modified):
>>>>
>>>> http://pat.github.io/thinking-sphinx/advanced_config.html#large-result-sets
>>>>
>>>> I’m not sure I quite understand what you’re after, though… if you want 
>>>> the item_variations loaded from the database alongside each item (eager 
>>>> loading), then you can pass through either :joins or :include options 
>>>> nested within the :sql option. Same goes for :select.
>>>> http://pat.github.io/thinking-sphinx/searching.html#advanced
>>>>
>>>> It’s worth noting, though, that Sphinx itself has no concept of joins - 
>>>> there’s no way to tie one index to another.
>>>>
>>>> Does that help? Have I missed something?
>>>>
>>>> — 
>>>> Pat
>>>>
>>>
>>> -- 
>>> 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 thinking-sphi...@googlegroups. <http://googlegroups.com/>com 
>>> <http://googlegroups.com/>.
>>> 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].
>> To post to this group, send email to thinkin...@googlegroups. 
>> <http://googlegroups.com/>com <http://googlegroups.com/>.
>> 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