Features - branch 2.x results in large info files that exceed the 'info' column limit in the 'system' table

Question

Original thread on DO (will keep it up to date)

Hello. I am currently developing a mid-to-large project. As i've done before, but using the 1.x branch, I use Features to track all structural and functional components of my site in order to be able to transfer them from my local installation, to the staging server, to the production server etc, while also having svn capabilities and tracking.

The current project consists of 45 Content Types with an average of 15 fields each. There are also ~15 vocabularies, ~10 fieldgroups, and a couple of tons of views.

The problem occurs when trying to track all this stuff with Features. It produces a large (initially, just alpha versions of the Content Types) .info file ( > 100K) which results in the following error:

PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'info' at row 1: UPDATE {system} SET info=:db_update_placeholder_0 WHERE // yada yada yada serialized array of the .info file

Which is totally natural seeing that the collumn is declared as a BLOB.

My question, is how should one go about to manage such a problem?
1) perform a ALTER TABLE system CHANGE info info LONGBLOB /* or MEDIUMBLOB */ NULL DEFAULT NULL? (Ouch)
2) Use branch 1.x instead which is less verbose in the .info file declarations?
3) Break down the project and track it in multiple features? (I'd avoid this cause it will make reverting those features a hellish job since one would depend on the other and vice versa)
4) ...?

I'd appreciate any input on the matter

Answer 1

The way I see it, you have options:

Features

Break your Features down into smaller Features. Yes, this might make the dependencies a little more effort to manage, but a Feature containing that many content types, as well as other config does seem a little extreme.

If you do break them up, and are worried about dependencies, create a controller module to deal with them. Every time you add/break down a Feature, add it as a dependency to this controller module, then make your new Feature depend on the controller module.

This means that all other dependencies will be inherited by the Feature, but you've only had to declare it in one place. When you then disable any part of your Feature, everything will get disabled - which is the same behaviour as having one monolithic Feature.

As an added bonus, if you perform updates to your Features that require hook_install or hook_update_N, they can go in the controller module.

Configuration Management

If the idea of breaking down your Features really sends shivers down your spine, then check out Configuration Management, which can do what you want (track EVERYTHING), and if pretty easily extensible if you are happy writing your own code. This is also the route Drupal 8 is taking/has taken with configuration management, so with this method you'll be future-proofing your own knowledge.

My personal preference is Features, but if you are looking for something that wouldn't involve you breaking down a huge Feature into smaller ones, then Configuration Management is a solid option.

Answer 2

The error happens, because info column is not long enough to serialize data from .info file of the module.

The solution includes:

• breaking down your Feature module into smaller pieces (e.g. by separating components by type, or by base definition and its instances),
• increasing size of info column.

If you decide to increase info column, you've the following possibilities:

• apply simple Drupal core patch from: Increase size of info column in system table (and re-install Drupal),

• run the following one-time off SQL query:

  ALTER TABLE `system` CHANGE `info` `info` LONGBLOB /* or MEDIUMBLOB */ NULL DEFAULT NULL
  

• more Drupal way is to change the field by using: db_change_field:

  • as one-time run, either from the code (e.g. as hook_update_X):

    db_change_field("system", "info", "info", array('type' => 'blob', "size" => "big"));
    

    check some field change examples in system_update_7055(),

  • or using drush:

    drush ev 'db_change_field("system", "info", "info", array('type' => 'blob', "size" => "big"));'
    

  • or using appropriate hook (e.g. hook_system_info_alter) which could not work properly for system table,

  • on Drupal install, some example with profile install:

    /**
     * Custom callback to recreate system table.
     *
     * This fixes Drupal issue when data is too long for column 'info'.
     * This happens for large feature modules.
     * @see: https://www.drupal.org/node/2580473
     */
    function myprofile_install_system() {
      try {
        drupal_install_system();
      } catch (PDOException $e) {
        // This catches: SQLSTATE[22001]: Data too long for column 'info'.
        // Then we alter info column in order to resize it.
        db_change_field("system", "info", "info", array('type' => 'blob', "size" => "big"));
      }
      // Rebuild, save, and return data about all currently available modules again.
      system_rebuild_module_data();
    }
    
    myprofile_install_system();
    

    however this could have some side effects.