Hi Simon

Just so I'm aware of what we're working with, can you share your  
define_index block? Also, what version of Rails are you using? The  
attribute-only-updates requires @instance.changed? support - which  
either came in on 2.1 or 2.2 (I'm not sure which).

As for whether the tarball has got the latest, if it has the file  
attribute_updates in lib/thinking_sphinx/active_record, then it should  
be fine.

Cheers

-- 
Pat

On 18/05/2009, at 1:17 AM, Simon wrote:

>
> I updated the plugin this morning, and it still doesn't seem to be
> working.  I have it set up in the manner you described above (using a
> has and :with).  Could there be an issue with my also having a
> conditions hash on the query, or having a where clause in my
> define_index block?  I don't see any indication of the locked = false
> in the log, but I'm not sure if that would show up at all anyways.
>
> I also had to update using the tarball (from
> http://github.com/freelancing-god/thinking-sphinx/tarball/master), as
> when I tried to install the plugin using "script/plugin install
> git://github.com/freelancing-god/thinking-sphinx.git" I was getting
> back the error "Plugin not found: ["git://github.com/freelancing-god/
> thinking-sphinx.git"]".  Perhaps the tarball wasn't updated to the
> latest version?
>
> Simon
>
> On May 16, 10:09 pm, Pat Allan <[email protected]> wrote:
>> Hi Simon
>>
>> Ideally the boolean column should do the job. It depends on how  
>> recent
>> your version of Thinking Sphinx is though... I only made the changes
>> for attribute-updating two weeks ago.
>>
>> All you'll need to do is have the boolean column as an attribute:
>>    has locked
>>
>> And then filter on that when you're making your search queries:
>>    Model.search "words", :with => {:locked => false}
>>
>> If you did want to go down the delta path though and want to keep the
>> tasks asynchronous, there is the Delayed Job approach, and Workling
>> (written by Dan) - search around on the list for info on the 
>> latter.http://freelancing-gods.com/posts/thinking_sphinx_delta_changes
>>
>> --
>> Pat
>>
>> On 16/05/2009, at 3:05 AM, Simon wrote:
>>
>>
>>
>>> Hi Pat,
>>
>>> I'm not sure I fully understand what you mean.  I have a boolean
>>> (tinyint(1)) column in my DB, and I could use this to indicate the
>>> locked entry.  I have added it to my define_index block using 'has
>>> column'.  I then tried adding a condition to both my where clause in
>>> the define_index block, and also within the conditions hash on my
>>> actual search call, but nether seem to behave as you have indicated.
>>> If the boolean value is updated, the search results do not change.
>>> Have I misunderstood what you meant?
>>
>>> I think I could also achieve what I need using Dan's suggestion, but
>>> if I could avoid the overhead caused by the delta indexing  
>>> altogether,
>>> that seems like a more desireable outcome.  If I do end up using the
>>> delta indexing, is there a way to make it an asynchronous task, so
>>> that it does not block on the UI rendering?
>>
>>> Thanks again,
>>
>>> Simon
>>
>>> On May 14, 8:52 pm, Pat Allan <[email protected]> wrote:
>>>> Hi Simon
>>
>>>> If a locked entry is indicated by a boolean attribute in the index,
>>>> then you shouldn't even need delta indexes. Thinking Sphinx now
>>>> updates attributes on the fly, given the following:
>>>> * The attribute is an integer, timestamp or boolean
>>>> * The attribute is generated from a straight database column -  
>>>> not a
>>>> manual SQL stirng
>>
>>>> If your locking is a bit complex though, then Dan's suggestion
>>>> about a
>>>> custom delta indexer is probably the better solution.
>>
>>>> Cheers
>>
>>>> --
>>>> Pat
>>
>>>> On 14/05/2009, at 5:41 AM, Simon wrote:
>>
>>>>> Hi,
>>
>>>>> I have a situation where I have lots of users concurrently  
>>>>> creating/
>>>>> updating entries that I have indexed.  I think I can get away with
>>>>> just running ts:index once an hour or so to get relatively up to
>>>>> date
>>>>> results.  My issue is that users also have the option to lock
>>>>> entries,
>>>>> at which point they should not be returned by search results.   
>>>>> If I
>>>>> have delta indexing enabled, this works perfectly, however it also
>>>>> really impacts the overall system performance, since the delta
>>>>> indexing is also triggered for any other new/modify operation.
>>
>>>>> What I would like to do is to be able to only trigger a delta  
>>>>> index
>>>>> when an entry is locked, and not when any other create/modify
>>>>> operation is done.  Is there a way to achieve this?  The only  
>>>>> other
>>>>> option I can think of is to trigger a full index task when an
>>>>> entry is
>>>>> locked, in addition to what I have scheduled in a cron job.
>>
>>>>> I have also noticed that the UI hangs when an entry is created/
>>>>> modified, as the delta indexing is being done.  Is there a way to
>>>>> push
>>>>> this to a background or asynchronous process so that it doesn't
>>>>> interfere with the UI rendering?
>>
>>>>> Thanks,
>>
>>>>> Simon
> >


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Thinking Sphinx" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/thinking-sphinx?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to