- I don't like the explicit "field_purge_batch()" call added after the "field_delete_field()" in forum_uninstall().
That's a convoluted DX pattern for module developers - "on uninstall, after deleting the fields you created on install, don't forget to run an explicit purge pass, so that users with few field data (e.g people just evaluating a module) can disable the field type modules right after that"
field_purge_batch(reasonable N) should be taken care of within field_delete_field(). Problem is, node type deletion (or, worse, uninstall of an entity type, = deletion of all bundles) can cascade to 10(0)s of field deletions, so we probably want to control that automatic purge by an optional param for field_delete_field().
Besides, the current field_purge_batch() call won't work as intended right now :
- If there are already fields/data pending deletion, there's no guarantee that this purge pass will clear the very data you want to clear. This would require an additional $field_name param for field_purge_batch() to clear the data from a specific field.
- If the field had data, completely clearing the data+instance+field requires at least *two* field_purge_batch() calls.
See the code logic over there : if the EFQ returns no result (all data has been purged), then wipe the instance and field.
Should be switched to : if the EFQ returns less results than the number we asked for, then wipe the instance and field.
FAILED: [[SimpleTest]]: [MySQL] 33,339 pass(es), 14 fail(s), and 13 exception(es).
FAILED: [[SimpleTest]]: [MySQL] 33,319 pass(es), 27 fail(s), and 26 exception(es).
PASSED: [[SimpleTest]]: [MySQL] 34,167 pass(es).
PASSED: [[SimpleTest]]: [MySQL] 34,173 pass(es).
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch field_purge-1264756-6.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.