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

Comments

mpotter’s picture

mpotter CreditAttribution: mpotter commented
Status: Active » Closed (won't fix)

You shouldn't be putting everything into a single feature. You should be splitting it into smaller features. Features is designed to bundle related config around particular functionality (for example, content type + fields + views for a photo gallery feature). It's not meant to be a place to dump your entire config.

Putting everything into a single feature has several really bad results:

a) You end up with large features.*.inc files that will cause version control merge conflicts when multiple developers are working on the site.
b) Changing anything on your site will cause your huge feature to be marked as Overridden. So you'll always be rebuilding the same huge feature export.

So really, #3 is what you want to do. It will save you tremendous grief in the future.

Properly figuring out the dependencies and structuring your features in a module way is just part of properly architecting your web site. Again, the work you spend making sure the correct functionality is modularized into smaller features will improve your entire site architecture and make your site more maintainable in the future.

magtak’s picture

magtak CreditAttribution: magtak commented

Thanks a lot for the feedback mpotter.

EDIT: drush fu-all and drush fr-all seems to solve my issues. Now I'll just have to packet up my project into schemantically relevant compontents :)