DevPortal unstable state - ERROR: relational "drupal_" does not exist

[omarld]

Have you ever seen an error message in your logs that makes you say, "What?! This doesn't tell me anything!" Well, we recently saw such an error and it turns it out that it was useful it's just that we were not familiar with the system yet.

This is the error we saw and it got us running around trying to figure what was going on for over a week -

"ERROR: relational 'drupal_' does not exist at character 18"

"STATEMENT: SELECT t.* from drupal_ t WHERE (name = 'company_invitation_non_mint')"

We just recently integrated Apigee into our systems along with DevPortal, and Drupal is new to us as well. So we have a learning curve.

So, what caused our issue? It turns out that during our last deployment we found that our deployment environment was missing some configurations, which left our DevPortal instance unstable. Restarting the application caused the database (postgresql) to be unstable, and unable to detokenize the table name to query. As we know now, all tables are prefixed with "drupal_" (note, this is in your settings.php).

Here are some more details into the debugging steps we took. Hopefully, this can help you or at least guide you if you see a similar issue.

• Deployment environment had missing configuration, specifically the location of service. We needed to create directory for apigee-drupal-devportal service in ‘init.d’.
  • This is why DevPortal was not able to restart on server reboot
  • We addressed this issue, and was able to restart the webapp
• On login, there was a DB error thrown on module ‘apigee_nonmint_company’, which uses ECK (third party module, an ORM) to query database.
  • Error was that it could not find table ‘drupal_’, this error is not very clear which let us to explore many possibilities. From issues with settings.php file, to file and folder permissions.
• Other bottleneck we had is that the cache clearing tools, both on DevPortal and drush did not work.
  • This is because they both iterate through all modules before clearing cache, which would fail with same error as above once it got to module ‘apigee_nonmint_company’
  • After exploring many options, we finally decided it was time to truncate all cache tables. That’s any table with 'cache' in the table name.

These are the specific tables, but before truncating all cache tables we first tried truncating ‘drupal_cache_eck’ to try to isolate any potential impact, but that didn’t work.

truncate table drupal_cache;
truncate table drupal_cache_admin_menu;
truncate table drupal_cache_block;
truncate table drupal_cache_bootstrap;
truncate table drupal_cache_devconnect_developer_is_active;
truncate table drupal_cache_eck;
truncate table drupal_cache_features;
truncate table drupal_cache_field;
truncate table drupal_cache_filter;
truncate table drupal_cache_form;
truncate table drupal_cache_image;
truncate table drupal_cache_libraries;
truncate table drupal_cache_menu;
truncate table drupal_cache_page;
truncate table drupal_cache_path;
truncate table drupal_cache_rules;
truncate table drupal_cache_token;
truncate table drupal_cache_update;
truncate table drupal_cache_views;
truncate table drupal_cache_views_data;
truncate table drupal_ctools_css_cache;
truncate table drupal_ctools_object_cache;

Clearing out these tables is similar to running 'drush cc all'.

You can find out more about clearing cache here : https://www.drupal.org/docs/7/administering-drupal-7-site/clearing-or-rebuilding-drupals-cache

Hope this is helpful!