When deleting fields I made on a Basic Page, I am getting the following left in the database:

field_deleted_data_7
field_deleted_data_8
field_deleted_data_9
field_deleted_data_10

with corresponding:

field_deleted_revision_7
field_deleted_revision_8
field_deleted_revision_9
field_deleted_revision_10

What is the purpose to leave these in the database?

Trying to delete them causes Bootstrap errors.

Thanks,
Tim

Comments

nevets’s picture

I do not know the details, but from a comment I saw wondering through the code, they are used for housekeeping, the fields do not seem to be deleted in real time but as part of cleanup code I suspect runs during a cron run.

Tim Jones Toronto’s picture

Thanks, I saw some discussion on this but nothing confirmed specifically.

It would be nice to get this behavior confirmed/documented officially on the Drupal site and to whether cron is involved (I have run cron - maybe I should wait a week and see what happens ;) lol?).

mabho’s picture

Works for me after running cron. All the leftover tables were removed. Thank you for the advice.

Anonymous’s picture

I also found same. can I drop from phpmyadmin?

scott.whittaker’s picture

I've got dozens of these in my DB and they don't seem to be ever getting garbage collected. If I manually delete them I get DB errors. WTF?

timb’s picture

subscribing

- bbros.us -
Who else is interested in Lunch?

palwakeup’s picture

please see the folowing codes

in drupal 7.9
field/modules/text/text.install line 79
field/modules/field_sql_storage/field_sql_storage.module line 277

it seems they want change the spec of a column,
but some fields has data so they cannot change them.

convert it to a table and change it differently and use it.

timb’s picture

I just dropped 6 of these tables via phpmyadmin and my site is still running fine

- bbros.us -
Who else is interested in Lunch?

timb’s picture

next time i went to delete a field - i received errors about missing tables. to fix this you need to delete the referencing lines in both the following tables: field_config_instance, field_config. This is easy to do since you can sort by deleted in the table.

- bbros.us -
Who else is interested in Lunch?

Shai’s picture

@timb,

4.5 years later your having taken the time to share a solution saved me frustration and time.

Thank you!

thejacer87’s picture

worked for me!!

tecjam’s picture

I find it hard to believe that there is no info here for this.

I had 2 image type fileds I deleted from my content type - yes, it contained content, but I migrated it to 1 single 'new' image type field.

Now I have 2 of these, well 4 actually if I include the revision table for it,

_field_deleted_data_9
_field_deleted_data_53
_field_deleted_revision_9
_field_deleted_revision_53

Also, all the files details I uploaded are still in the

_file_managed
_file_usage

and in the

_filefield_paths tables.

The fields are also still found in the _field_config and _field_config_instance tables.

Before we go live I would like to clean up the db and remove any old crap that we uploaded for testing purposes. Now how do I go about this without breaking the site if these are partially still referenced and why doesn't drupal clean up after itself?

Josh Clark’s picture

I was working on a module using field_create_field, field_create_instance, and field_delete_instance, and now I have a dozen or so of these tables stuck in my database.

pcoucke’s picture

I deleted all these tables after migrating from Drupal 6 to 7 with CCK Content Migrate:
content_type_*
content_field_*
field_deleted_data_*

During cron runs I got a warning about a missing table, which was fixed after running this:
delete from field_config_instance where deleted = 1;
delete from field_config where deleted = 1;

Not really sure where these are needed for however, some docs would be nice :-D

chartmann’s picture

I just ran across the function that creates these tables in field_sql_storage.module. I don't have time to look into it, and I knew I'd forget to post about this later, so I thought I'd at least mention that much.

kruser’s picture

I found that if you just delete the field_deleted_data_* and field_deleted_revision_* tables then it can cause errors when deleting other fields down the road.

So make sure after you delete those tables, also go into the "field_config" and "field_config_instance" and remove any rows where the "deleted" column equals "1".

-----------------------------------------------------
Bob @ Drupal Aid (https://www.drupalaid.com)

geerlingguy’s picture

Those tables will eventually be cleared by field_purge_batch; after about six hours (I think), cron runs will begin clearing out the tables. Things are done this way to avoid causing the actual field deletion operation to take too long.

If you want to clear them out sooner, make sure you delete the table itself, then delete the corresponding (now expired) records from {field_config} and {field_config_instance} (they should be marked with 'deleted' = 0—that's how the field module knows to delete them after a certain amount of time).

__________________
Personal site: www.jeffgeerling.com

rboedeker’s picture

I just ran cron and my "deleted" tables were gone...

bigjim’s picture

Correct me if I'm wrong but wouldn't it be the ones where deleted =1 ?

Pryrios’s picture

Just FYI, in case anyone has the same trouble I've had.

Somehow, one of the field_deleted_data tables went missing and that was causing a MySQL error appearing on watchdog. As I didn't develop this project and I saw many errors and wrongdoings on it, I didn't gave it importance until now because website just worked (you know, if it works, don't touch it).

Today I needed a new content type with some fields and without body. Drupal gave me errors just after creating content type and then after deleteing body field from it. On production site it gave the same errors. Not just drupal_set_message errors, but whole screen Drupal error. Fields and content types were created and worked, but those errors got me nervous.

After checking on logs again, I saw that "table does not exist" MySQL error poping up on every cron call and I got suspicious. After some deep googleings and drupalings, I arrived here and followed advice on deleting rows in field_config and field_config_instance.

Now, creation of content type and creation/deletion of entity fields works like charm. Hope someone knowing better what's going on here documents it.

cheers.

frederickjh’s picture

From the information I am finding that when you delete fields, the fields are not deleted immediately but are deleted 10 rows of data per cron run. That is why these tables "hang" around.

For more information or to give your input on how to improve this see:
Message "Required by Drupal (Fields Pending Deletion)" baffles users

berenddeboer’s picture

You can manually call field_purge_batch(): drush php:eval 'field_purge_batch(5000);' 

You may need to provide a very big value. At some point the uninstall will work.