Issue with field_features_rebuild()

Hi there,

Just had some issue using features with my install profile.
As soon as I enable the exported module in the install profile I see this nasty error:

WD php: DatabaseSchemaObjectExistsException: Table
         [error]
field_data_field_course_reference already exists. in
DatabaseSchema->createTable() (line 614 of
W:\htdocs\eurocentres\drupal\includes\database\schema.inc).
DatabaseSchemaObjectExistsException: Table <em class="placeholder">field_data_field_course_reference</em> already exists. in DatabaseSchema->createTable() (line 614 of W:\htdocs\eurocentres\drupal\includes\database\schema.inc).

Digging down I've found the issue in the method field_features_rebuild().
This method creates / resets the field_config to the default configuration according to the exported definition.
While using an installation profile this method is called twice. First there's a the installation process which flushes the caches, then there's a cron run which does the same.
Each cache flush triggers features_flush_caches -> features_rebuild -> field_features_rebuild

That wouldn't be a problem if there wouldn't be the "id" in the field definition export. On field_config creation the id is ignored, but on field update it's used.
Thus in the worst case the second call of field_features_rebuild will overwrite a field_config item that doesn't belong to the current used settings.

Here an attempt to visualize that:

$fields[] = array(
	'id' => '2',
	'field_name' => 'a',
	);
$fields[] = array(
	'id' => '3',
	'field_name' => 'b',
	);

Table field_config after first run:

Table field_config after second run (used id in definition):

The fix for that is very easy. I've just added a unset($field['id']); before the call of field_create_field / field_update_field.
It won't affect field_create_field - because id is ignored anyway.
And it won't affect field_update_field - because the method works with field_name.

Cheers,
Peter