In the various convert X to field patches, I've kept running into an issue with _field_info_fieldable_types() but didn't get to making an issue about it yet.

The current example in HEAD where this is a problem is taxonomy_entity_info(), which needs to use vocabulary names as bundles. The obvious thing to do there, would be to call taxonomy_get_vocabularies() - but taxonomy_get_vocabularies() calls entity_load() down the line, which requires the output of taxonomy_entity_info(), and BOOOM! The workaround for this was using taxonomy_get_vocabulary_names(), but that's not ideal.

Also, I want to put some field_create_field() stuff in taxonomy_install() - but that led to PDO exeptions for vocabulary tables which hadn't been created yet - presumably again due to the close relationship between the various fields and entities, and the fact that _field_info_fields() and friends all call back to a central routing function which requires aggregating information about everything on the site when it's not cached (notably when installing Drupal).

Marking as a critical bug, but it might be that there's not actually a clean way 'round this, and we just need to document it really, really well what you can and can't do there - but we need to do something, because there's strange things going on in there.

Comments

yched’s picture

yched CreditAttribution: yched commented

The current example in HEAD where this is a problem is taxonomy_entity_info(), which needs to use vocabulary names as bundles. The obvious thing to do there, would be to call taxonomy_get_vocabularies() - but taxonomy_get_vocabularies() calls entity_load() down the line, which requires the output of taxonomy_entity_info(), and BOOOM! The workaround for this was using taxonomy_get_vocabulary_names(), but that's not ideal.

Mh. The tricky bit is that taxonomy.module exposes both 'term' and 'vocabulary' as entities (vocabularies are not fieldable, but they use the 'multiload' features), so you cannot rely on the entity info of the one to build the entity info of the other.
The workaround you used makes sense, you need a way to directly access the list of 'things' that you expose as your bundles.
A more radical fix would be to refactor the list of bundles out of hook_entity_info() into a separate field_bundle_info() hook. Ugh :-(

Not sure about the field_create_field() stuff in taxonomy_install() for now.

yched’s picture

yched CreditAttribution: yched commented

"The workaround you used makes sense, you need a way to directly access the list of 'things' that you expose as your bundles."
+ that also makes sure rebuilding the list of bundles is a not too costly operation. Having to call a full fledged entity_load() to rebuild the fieldable info is kind of heavy.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

Yeah the term bundles seemed like not too bad a compromise to have clean API elsewhere, hence not opening an issue. The comment_install() was alarming, but then I realised I didn't really want to do that anyway, so forgot about it, until pwolanin noticed a flaw not doing it in comment_install().

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented
Priority: Critical » Normal

This hasn't bitten anyone recently, and it may well be that taxonomy module is a specific case providing two entity types and a field all of which are closely related, so downgrading.