Make WordPress Core

Opened 13 years ago

Closed 18 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 11 years ago.
meta cache implementation (based upon get_posts cache)
23327-unit_tests.diff (4.2 KB) - added by jipmoors 11 years ago.
Unit tests

Download all attachments as: .zip

Change History (14)

#1 @ryan
13 years ago

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

#2 @wonderboymusic
13 years ago

  • Milestone changed from Future Release to 3.7

these are all marked 3.7-early

#3 @nacin
12 years ago

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

Needs a patch.

@jipmoors
11 years ago

meta cache implementation (based upon get_posts cache)

#4 @jipmoors
11 years ago

  • Keywords has-patch needs-unit-tests added

#5 follow-up: @jipmoors
11 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
11 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
11 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
11 years ago

Unit tests

#8 @jipmoors
11 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
11 years ago

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

#10 @ocean90
10 years ago

  • Type changed from task (blessed) to enhancement

#11 @johnbillion
4 years ago

  • Keywords 3.7-early removed

#12 @desrosj
18 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.