Make WordPress Core

Opened 12 years ago

Closed 3 months ago

#23327 closed enhancement (wontfix)

Cache incrementors for get_bookmarks()

Reported by: ryan's profile ryan Owned by:
Milestone: Priority: low
Severity: normal Version: 3.5.1
Component: Cache API Keywords: has-patch
Focuses: Cc:

Description

Make use of a caching incrementor and store queries in individual cache buckets to avoid memory exhaustion.

Pattern this after #23167, which does the same thing for get_pages().

See #23173 for an explanation of the motivation behind this.

Attachments (2)

23327-meta_cache_bookmark_ids.diff (3.1 KB) - added by jipmoors 10 years ago.
meta cache implementation (based upon get_posts cache)
23327-unit_tests.diff (4.2 KB) - added by jipmoors 10 years ago.
Unit tests

Download all attachments as: .zip

Change History (14)

#1 @ryan
12 years ago

  • Keywords 3.7-early added
  • Milestone changed from 3.6 to Future Release

#2 @wonderboymusic
11 years ago

  • Milestone changed from Future Release to 3.7

these are all marked 3.7-early

#3 @nacin
11 years ago

  • Milestone changed from 3.7 to Future Release
  • Priority changed from normal to low

Needs a patch.

@jipmoors
10 years ago

meta cache implementation (based upon get_posts cache)

#4 @jipmoors
10 years ago

  • Keywords has-patch needs-unit-tests added

#5 follow-up: @jipmoors
10 years ago

I had a slight problem with figuring out how to create a unit-test that would consider the current 'defaults' from get_bookmarks, since that data is only available in the function itself.

This is the most important part in the generation of the cache key, so it will be very difficult to test without knowing this and not have it break when the defaults might be modified in the future.

Any advice/suggestions on that?

#6 in reply to: ↑ 5 ; follow-up: @SergeyBiryukov
10 years ago

Replying to jipmoors:

This is the most important part in the generation of the cache key, so it will be very difficult to test without knowing this and not have it break when the defaults might be modified in the future.

Link manager is disabled for new installs (see #21307), so it's very unlikely for those defaults to change.

#7 in reply to: ↑ 6 @jipmoors
10 years ago

Replying to SergeyBiryukov:

Link manager is disabled for new installs (see #21307), so it's very unlikely for those defaults to change.

Alright, I'll write a test for it then and put some additional commentary in there. Thanks for the reply.

@jipmoors
10 years ago

Unit tests

#8 @jipmoors
10 years ago

  • Keywords needs-unit-tests removed

Please be critical about the unit tests, these are a couple of my first ones so I'm sure there is room for improvement.
On a side note (not an excuse): the bookmarks are kind of old and should not take up too much energy and time I think.

#9 @jipmoors
10 years ago

I'm getting some fails on the unit tests. Could somebody give me some pointers on those?

#10 @ocean90
8 years ago

  • Type changed from task (blessed) to enhancement

#11 @johnbillion
3 years ago

  • Keywords 3.7-early removed

#12 @desrosj
3 months ago

  • Resolution set to wontfix
  • Status changed from new to closed

I'm going to close this out as a wontfix.

The Link Manager was essentially deprecated in Core when it was disabled by default for new installs, and hidden entirely when no links were present on a site updating in WP 3.5 (see #21307).

I've also opened #56362 to transition the related code out of Core and into a canonical plugin. If it's determined in the future that this is beneficial once transitioned to plugin form, then an issue should be opened upstream where that code is managed.

Note: See TracTickets for help on using tickets.