Please stop using draft_autosave variables, use a separate table instead.

Let me explain. I took over management of a site with ~5,800 nodes and ~8,000 users. While starting to clean it up, including exporting functionality to Features, as soon as I turned on Strongarm to export variables it completely choked my browser as Features tried to load ~22,000 values into a dynamically generated selector, 20,000 of them starting with "draft_autosave"! This is not how variables should be used! A much more efficient way would be to add a new table for storing the user data, or just adding it to the $user object and storing it in {users}.data.

CommentFileSizeAuthor
#3 draft-n1135606-3.patch6.38 KBdamienmckenna

Comments

damienmckenna’s picture

Title: Stop using draft_autosave variables! » Stop using draft_autosave_$uid and draft_autosave_interval_$uid variables!

Clarified the title.

damienmckenna’s picture

Clarification - Features dynamically was trying to dynamically create 22,000 checkboxes, not load them all into a selector. It was also loading them into JS variables on page load rather than via an AJAX call, so loading admin/build/features/create or admin/build/features/[myfeature]/recreate killed my browser.

damienmckenna’s picture

Status: Active » Needs review
StatusFileSize
new6.38 KB

This patch retains use of the variables, however it keeps track of the default draft_autosave_X and draft_autosave_interval_X variables and then only saves new variables if they're different to the default; further it adds a hook_update_N script to purge any variables which match the defaults and updates hook_uninstall to also remove these variables so they aren't left hanging around after the module is uninstalled.

Drave Robber’s picture

Indeed. I was just looking at a site which had 11k rows in the variable table, and most of those turned out to be draft_autosave_*. This sort of thing is bad enough even without Features.

Going to take a closer look at the patch over the weekend. (at least I hope so)