Opened 22 months ago

Last modified 22 months ago

#18356 new defect (bug)

get_bookmarks() indefinitely caches randomly ordered results

Reported by: prettyboymp Owned by:
Priority: normal Milestone: Awaiting Review
Component: General Version:
Severity: normal Keywords: has-patch needs-testing
Cc:

Description

The get_bookmarks() function caches the results of all requests to the function in a single cache result so it can clear all the items when a new book mark is added. However, randomly ordered results shouldn't be cached indefinitely. This specifically affects the Links widget as it never refreshes when set to random order.

Attachments (2)

18356.diff (1.8 KB) - added by prettyboymp 22 months ago.
18356.2.diff (1.6 KB) - added by prettyboymp 22 months ago.
switching to separate cache with shorter cache timeout

Download all attachments as: .zip

Change History (9)

  • Keywords needs-patch added
  • Keywords has-patch needs-testing added; needs-patch removed

comment:3 follow-up: ↓ 5   SergeyBiryukov22 months ago

$orderby == 'rand()'

Shouldn't it be $orderby == 'rand' (without brackets)?

comment:4 follow-up: ↓ 6   westi22 months ago

I'm not sure why you are re-implementing the expiration functionality that is already built into the caching system here.

If we need to use a different cache bucket and add expiration for RAND requests lets do that but don't implement a second level of expiration when we have one already.

comment:5 in reply to: ↑ 3   prettyboymp22 months ago

Replying to SergeyBiryukov:

$orderby == 'rand()'

Shouldn't it be $orderby == 'rand' (without brackets)?

It's 'rand()' at that point because the $orderby variable is reused when building the query in the case statement.

comment:6 in reply to: ↑ 4 ; follow-up: ↓ 7   prettyboymp22 months ago

Replying to westi:

I'm not sure why you are re-implementing the expiration functionality that is already built into the caching system here.

If we need to use a different cache bucket and add expiration for RAND requests lets do that but don't implement a second level of expiration when we have one already.

The problem with creating a new cache bucket is that you can't purge it automatically after modifying the bookmarks.

comment:7 in reply to: ↑ 6   westi22 months ago

Replying to prettyboymp:

Replying to westi:

I'm not sure why you are re-implementing the expiration functionality that is already built into the caching system here.

If we need to use a different cache bucket and add expiration for RAND requests lets do that but don't implement a second level of expiration when we have one already.

The problem with creating a new cache bucket is that you can't purge it automatically after modifying the bookmarks.

Yes, but if it has a shortish expiration which is what you are suggesting here to deal with the RAND issue then that doesn't really matter.

switching to separate cache with shorter cache timeout

Note: See TracTickets for help on using tickets.