Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Caching issue on assembly product pages (product cache key) #168

Open
jkelleyj opened this issue Nov 3, 2017 · 1 comment
Open

Caching issue on assembly product pages (product cache key) #168

jkelleyj opened this issue Nov 3, 2017 · 1 comment

Comments

@jkelleyj
Copy link

jkelleyj commented Nov 3, 2017

Problem description

When an assembly's part is updated, it is not updating the timestamp on the assembly itself. This can cause the product page for the assembly to be out of date. The cache key on the product page in frontend relies on the cache_key of the Spree::Product. Since touching/saving a variant that is a part of the assembly does not update the assembly's updated_at timestamp, the page can be out of date, looking in stock when it is actually out of stock.

Recommended solution

In the variant decorator, we can simply add the following:

after_touch :touch_assemblies
def touch_assemblies
  self.assemblies.map(&:touch)
end

This should reliably update the assembly variant and through it the product record's updated_at timestamp. I'm not certain that this will handle deferred variant's correctly, so an approach like this may work better on the product decorator.

after_touch :touch_assemblies, if: :can_be_part?

def touch_assemblies        
  assys = self.variants_including_master.joins(:assemblies).flat_map { |v| v.assemblies }.uniq
  assys.map(&:touch)
end

If no one sees an issue with this approach, I'm happy to submit a pull request.

@jkelleyj
Copy link
Author

jkelleyj commented Nov 3, 2017

The only concern I have about this solution is that it could cause infinite recursion. If a part touches an assembly that is a part of another assembly, touching it would trigger another round up the tree that could (in theory) loop back to the originating Part, causing infinite recursion.

https://github.com/spree-contrib/spree-product-assembly/blob/master/app/models/spree/product_decorator.rb#L14
This appears to prevent a variant from being both a part and an assembly, so I think the infinite recursion should never happen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant