Serialized data in FCI

We have a task for cleaning up the serialized data in the field_config_instance table. This includes preventing duplicate/inconsistent data from existing in the serialized data column and other columns, and considering whether some data now in the serialized column that did not used to be should in fact go back into its own column.

1. Preventing duplicate/inconsistent data

In _field_write_instance, we previously wrote $instance (the whole record) into the 'data' column. I changed the code like this:

I then write $data into the 'data' column. I think this eliminates the duplicate/inconsistent data problem. Am I missing something?

2. Serialized data vs. columns

The current FCI table stores data differently than CCK's field_instance table, but actually not as differently as I thought. Here are the differences:

• D6 CCK's widget_settings and display_settings columns, both of which are stored as serialized data, are now stored combined in the single serialized 'data' column. I do not see how this can adversely affect any hypothetical contrib module that wants to query the FCI table directly, since widget_settings and display_settings were not queryable before anyway.
• D6 CCK stores instance 'label' and 'description' as separate columns, and currently FCI stores them as part of the serialized 'data' array.

That's it. Every other column from D6 CCK's content_node_field_instance table still has its own column in FCI.

It is easy to promote label and description back to their own columns. Should I, or is this a non-issue?