Much to my surprise, someone decided to warm up the old debate about field storage, stating that Drupal 7 will be much less performant because of it. That Drupal 7 is a little slower than Drupal 6 is true, but that's not because of how we store fields (rather because the increased use of rendering) and it's not a terrible slowdown either (one can say it's a win when used wisely because of the render cache).

To recap, in Drupal 6 CCK have either stored field data in columns of a per content type (bundle in D7 terminology) table or in per field tables. For Drupal 7, core only ships with field storage per tables. There are many reasons for this. One, the primary perceived problem with this is JOINing these tables together and then filtering / ordering on more than one is not indexable. While it is true that filtering on multiple tables is not indexable, per bundle storage in itself does not solve everything and leaves a few questions unsolvable.

Yes, there is a per bundle storage module which stores a copy of the default tables into CCK-like per bundle tables. Because it's a copy only, there is no code to migrate between the two storage models (as that's not needed). This migrate code was, of course a real lot of code naturally rife with race conditions. Better not to have that in core. Yes, PBS module is not well maintained but as Drupal 7 will be more widely used I am sure that will change.

And then there is the slight problem when you want to run a query across bundles. Do you want nodes ordered by a field value, regardless of their node type? Good luck writing the necessary merge sort...

Unlimited cardinality, of course, can only be stored as a separate table anyways. Solving this with an artificial cap on cardinality has two challenges: too high and the processing code crawls to a halt, too low and it wont be enough one day.

Commenting on this Story is closed.