Problem/Motivation

We discovered that the imagefield_crop module poorly stores the crop info data inside the variables table. Crop information is per file. This creates a direct connection between the number of managed images in the system and the size of the variable in the variables table.

One of my sites has over 43,000 images with imagefield crop settings stored making this the largest variable in the variables table by a factor of 3000. Because the entire varibles table is loaded out of cache on every page load, this is not a scalable storage method.

Proposed resolution

Save the crop information in a data table. I'v attached a patch that creates the table and converts the variable into rows within the table.

API changes

The patch introduces two new functions for retrieving and saving cropping information. I tried using the entity load hook but it didn't work for some reason.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joetsuihk’s picture

Status: Needs review » Needs work

+1 for the idea, thanks or the effort. But I cannot apply the patch by `git -v apply [patchname]`
Should it applying to 7.x-1.1 or 7.x-1.x?

I am still unable to get this after manually apply the patch

I few suggestions:
rename imagefield_crop_file_settings() into imagefield_crop_file_settings_load()
in imagefield_crop_file_settings(), fetchCol() should be replaced by fetchAssoc()? Why you only need first column?

Josh Waihi’s picture

Yeah you're right, I did need to use fetchAssoc instead of fetchCol (See new patch attached).

Josh Waihi’s picture

BTW: patch applies fine with drush make (how I'm tracking the change).

zhgenti’s picture

Hi guys, 7.x-2.x was originally started to handle this issue with storing data in the variables table and other issues. I think what really would be great is to create an update path from 7.x-1.x to 7.x-2.x. I didn't have enough time to add this, but it's really worth doing it. I also thinking about 3.x version and going to create issue for discussion.

Cheers,
Dmitry

joetsuihk’s picture

Duplicate #1566060: Storing crop data in a variable doesn't scale well.. There is a patch from 2012 May also available for review. Heop we can combine the effort somehow.

reubenavery’s picture

Category: feature » bug
Priority: Normal » Critical
Status: Needs work » Needs review
FileSize
4.81 KB

Here's the same patch re-rolled against latest dev.

Upping the priority and changing this to bug report. This is a huge deal for sites with any significant number of nodes with cropped imagefields, and in my opinion is definitely a bug, not a feature request. Expecting variable_get and PHP to be a database is really really wrong.

wiifm’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community
FileSize
9.98 KB

Okay, had a look at the most recent attached patch, and have made a few changes:

  • hook_schema() is now laid out with more lines making it easier to read (no functional changes)
  • removal of the commented out dpm() function calls (why are these even in there?)
  • Misc trailing whitespace issues

Have tested the patch (used to have 35KB of data in the one variable imagefield_crop_info and now I have none), and all functionality appears intact, the update hook successfully migrated the data to the new schema.

Really happy with this approach, seems sane, and reduces a lot of deserialize PHP calls on every page request.

Marking as RTBC as my patch only enhances the previous patch by @reubenavery. Feel free to chime in with a +1 if this patch works for you too.

joetsuihk’s picture

Status: Reviewed & tested by the community » Needs review

Thanks @wiifm ! As this is an important change, involves database schema changes, I suggest we have one more reviewer before I commit this to dev. Marked the issue need review so others can help on this.

grota’s picture

Rerolled patch from https://drupal.org/node/1993144#comment-8269865 onto latest 7.x-1.x branch (sha 9c1653a as of today)

valthebald’s picture

Status: Needs review » Reviewed & tested by the community

Works like a charm for me

Bastlynn’s picture

Works perfectly on this end too. DB tables migrated fine.

Alex Bukach’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
5.61 KB

Rerolled patch from #9 for latest 7.x-1.x head.

Bastlynn’s picture

Status: Needs review » Reviewed & tested by the community

Still good...

Bastlynn’s picture

We ready to roll on this?

  • joetsuihk committed 6d5bf60 on 7.x-1.x
    Issue #1993144: by josh-waihi, reubenavery, wiifm, grota, alex-bukach,...
joetsuihk’s picture

Yes!

This is the latest patch i applied, #12 is a bit old.

commited to 7.x-1.x http://cgit.drupalcode.org/imagefield_crop/commit/?id=6d5bf60

Thanks everyone for the effort!

joetsuihk’s picture

Status: Reviewed & tested by the community » Fixed

mark as fixed

Bastlynn’s picture

woot! Thanks! :)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.