The Tripal package is a suite of Drupal modules for creating biological (genomic, genetic, breeding) websites. Visit the Tripal homepage at http://tripal.info for documentation, support, and other information. The Drupal project page is at http://drupal.org/project/tripal.
GNU General Public License v2.0
67
stars
49
forks
source link
Revisit schema settings for TripalEntity, TripalField and ChadoField #1999
Currently we have defined the schema for tripal_entity and its associated fields as we had to in response to automated test schema failures. However, this approach combined with (1) our limited knowledge and (2) lack of Drupal documentation regarding schema definitions, has resulted in a schema definition that does not follow what Drupal expects.
This has resulted in schema errors for any non-Tripal/Chado fields added to TripalEntities as seen in #1915 and is the reason that PR was closed without merge.
Observations
Drupal has a number of field specific YAML schema stanzas: field.storage_settings.[field_type], field.field_settings.[field_type], field.value.[type], field.formatter.settings.[formatter], field.widget.settings.[widget].
I think we will want to define stanza's like this for all our fields and include the settings there rather then what we are currently doing. I believe this will allow them to be used auto-magically by Drupal. I'm led to believe this by the stanzas like field.storage.*.* which defines the config type for settings as field.storage_settings.[%parent.type]. Based on reading that I've done the [%parent.type] notation means "fill this token in with the value of the type key one level above". In this case, that implies that the definition for the settings in all fields will be field.storage_settings.[field_type] which tracks with what I am seeing.
Notes
You can check the schema definitions for all of Drupal by implementing hook_config_schema_info_alter in the .module file and then exploring the $definitions array. Each key in this array matches with the key of a config stanza (e.g. field.storage.*.*). You can then add print_r statements to look at specific stanzas and the printed values will be shown on the command line when you clear the cache.
You will know if you broke the schema by running the automated tests. If the schema is not defined for anything you get annoying errors on EVERY test using an entity or field. For example, the errors caused by the organism field were:
Error adding field, "organism_image", to "organism": Schema errors for field.storage.tripal_entity.organism_image with the following errors: field.storage.tripal_entity.organism_image:settings.default_image missing schema, field.storage.tripal_entity.organism_image:settings.target_type missing schema, field.storage.tripal_entity.organism_image:settings.display_field missing schema, field.storage.tripal_entity.organism_image:settings.display_default missing schema, field.storage.tripal_entity.organism_image:settings.uri_scheme missing schema
Task Description
Currently we have defined the schema for tripal_entity and its associated fields as we had to in response to automated test schema failures. However, this approach combined with (1) our limited knowledge and (2) lack of Drupal documentation regarding schema definitions, has resulted in a schema definition that does not follow what Drupal expects.
This has resulted in schema errors for any non-Tripal/Chado fields added to TripalEntities as seen in #1915 and is the reason that PR was closed without merge.
Observations
Drupal has a number of field specific YAML schema stanzas:
field.storage_settings.[field_type],field.field_settings.[field_type],field.value.[type],field.formatter.settings.[formatter],field.widget.settings.[widget].I think we will want to define stanza's like this for all our fields and include the settings there rather then what we are currently doing. I believe this will allow them to be used auto-magically by Drupal. I'm led to believe this by the stanzas like
field.storage.*.*which defines the config type for settings asfield.storage_settings.[%parent.type]. Based on reading that I've done the[%parent.type]notation means "fill this token in with the value of thetypekey one level above". In this case, that implies that the definition for the settings in all fields will befield.storage_settings.[field_type]which tracks with what I am seeing.Notes
You can check the schema definitions for all of Drupal by implementing
hook_config_schema_info_alterin the .module file and then exploring the $definitions array. Each key in this array matches with the key of a config stanza (e.g.field.storage.*.*). You can then addprint_rstatements to look at specific stanzas and the printed values will be shown on the command line when you clear the cache.You will know if you broke the schema by running the automated tests. If the schema is not defined for anything you get annoying errors on EVERY test using an entity or field. For example, the errors caused by the organism field were: