Yeah, I will stick with the :retry_stale at the mo...thanks, seems to do what I wanted. But true, if I get a little bored later when cleaning up my app, I could be back for a little help.
Thanks for your help! D. On 8 Set, 14:51, Pat Allan <[email protected]> wrote: > Hi Daren > > I'm fairly certain inherited_resources would just be calling destroy - > so I'm not sure why the deletions aren't getting picked up by default. > If you're happy using :retry_stale, then just stick with that - I > wouldn't consider this a high priority :) > > That said, we could investigate further if you get bored :) > > Cheers > > -- > Pat > > On 08/09/2010, at 9:51 PM, docgecko <[email protected]> wrote: > > > > > Hi Pat, > > > thats a good question, because I am not sure...:-) > > > Well what I mean is: I am using the Inherited Resources gem by José > > Valim, and as such I haven't had to write any code for the destroy > > action (as its inherited from the ApplicationController). However, I > > believe its doing exactly what you suggested. > > > Does that mean that I do have a possible issue in my setup? It would > > be great if you had any suggestions! > > > Many thanks, > > > D. > > > On 8 Set, 01:22, Pat Allan <[email protected]> wrote: > >> Good to know you found the detail on retry_stale - although TS should > >> flag deletions (it's not part of deltas, should happen normally) if > >> you're calling #destroy on a model instance. Is this how you are > >> deleting objects? Or some other way? > > >> Cheers > > >> -- > >> Pat > > >> On 08/09/2010, at 1:39 AM, docgecko <[email protected]> wrote: > > >>> Well, in the end I found that my delta indexes were being updated by > >>> TS during a create or an update, but nothing was happening during a > >>> delete. > > >>> However, I simply modified by searches to include ":retry_stale => > >>> true" and any missing records are ignored. As stated here: > > >>>http://www.mail-archive.com/[email protected]/msg01411 > >>> ... > > >>> this will remove the nil results, add the :retry_stale option to > >>> your > >>> searches. It can be set to true, false, or an int. This will tell > >>> TS > >>> to remove any > >>> nil results, mark the relevant record as deleted in the index, and > >>> perform a new query to fill in the gap(s). > > >>> Excellent stuff hey! > > >>> Just need to add some more periodic indexing to reduce the chance of > >>> my indexes getting too big! > > >>> Hope this helps someone else out there! > > >>> Cheers, > > >>> D. > > >>> On 7 Set, 14:00, docgecko <[email protected]> wrote: > >>>> Hi all, > > >>>> I have a feeling this is a question on a common theme, but I just > >>>> can't seem to find the right answer from any previous posts. > > >>>> I am using TS set up with delta indexing, using Rails 3.0.0, Ruby > >>>> 1.8.7 and TS 2.0.0.rc2. > > >>>> A User can delete records from a table. Once the record is > >>>> deleted, > >>>> the User can see that the record is deleted in the Admin area of > >>>> the > >>>> application. For finding the users' records at this point, I > >>>> simply > >>>> use a the Rails "find_by..." to find records related to the current > >>>> user...so all works fine. > > >>>> These records can be seen by any User in the main app. However, > >>>> since > >>>> I am filtering the records in the main app using TS, when the user > >>>> goes to the main app (after a record has just been deleted), I > >>>> receive > >>>> an error. > > >>>> When I view the log file, TS still thinks the deleted record still > >>>> exists. However, once I "rake ts:reindex", TS's index excludes the > >>>> deleted file, and all starts working again. > > >>>> So I guess my question is, does this mean that my delta indexes are > >>>> not working? Or are my indexes not updating after records is > >>>> deleted > >>>> from a table? > > >>>> Would really appreciate any help given! > > >>>> Cheers, > > >>>> D. > > >>> -- > >>> 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 athttp://groups.google.com/ > >>> group/thinking-sphinx?hl=en > >>> . > > > -- > > 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 > > athttp://groups.google.com/group/thinking-sphinx?hl=en > > . -- 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.
