adamb

I'm not really sure yet. Are there implications to each? On Thu, May 19, 2016 at 10:12 PM, Nick [email protected] wrote: > Would you like to change the title on...

Just as a quick followup -- we have (temporarily?) removed `pg_search`, and re-implemented the parts we needed directly inside of our app, while _replacing the subquery_ with a normal `WHERE`...

In the example above, there is an index on `responses.sequential_id`, `responses.project_id`, and a GIN index on `responses.search_contents`. > We chose to add \* to the SELECT by default, which meant...

Sorry, fixed my comment. (Edits in italics.) I think we're on the same page now. I'll investigate a bit.

This occurs w/ both GIN and GIST indexes. There is also a compound index on project_id/sequential_id. Here's the complete list: 

Yeah, you've got it. Rails looks at the `virtual_path` in order to find the template file to digest: https://github.com/rails/rails/blob/92703a9ea5d8b96f30e0b706b801c9185ef14f0e/actionview/lib/action_view/helpers/cache_helper.rb#L204

I agree with you about dependency tracking, and not trying to implement it for Fortitude. I think that would quickly turn into a losing battle for the reasons you mention....

I'm having a lot of trouble getting my test suite to work properly, as well as getting this PR up-to-date with master, but I'm pretty convinced that the `virtual_path` stuff...

Gotcha! I suspect then, that the issue is that I'm calling `include ActionView::Helpers::CacheHelper` inside of `lib/fortitude/widget/caching.rb`, which means that when `cache` is called, it's no longer delegating to the anonymous...

I will have to get back to you on this, once I fix these broken tests :) On Mon, Oct 17, 2016 at 11:51 AM, Andrew Geweke [email protected] wrote: >...