Hi Pat, The Rails version is the issue then. I am getting this set up in Rails 1.2 - we are currently also making a switch to 2.2, so I will try the attribute updates again once I get this part of the project ported across. Thanks for all the help.
And the tarball did contain that file, so it is also up to date :) Thanks again, Simon On May 18, 8:46 pm, Pat Allan <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
