Caching issues are still present

Did you enable the meta tags that should be edited, and the ones that should be added in the HTML output?

One of the update functions flushes the cache; first, it flushed only the module cache, and now it flushed Drupal cache as well.

The update function I am talking of is the following:

/**
 * Implementation of hook_update_NN().
 */
function nodewords_update_6127() {
  $tables = array(
    'cache', 'cache_block', 'cache_filter', 'cache_nodewords', 'cache_page',
  );

  foreach ($tables as $table) {
    cache_clear_all('*', $table, TRUE);
  }

  $ret[] = array(
    'success' => TRUE,
    'query' => 'CLEAR DRUPAL CACHE',
  );

  return $ret;
}

I renamed the function to nodewords_update_6130(). If the problem is the cache, then the problem should be resolved.
I will check if there are some functions that need to clear the module cache, and they are not cleaning it.

Doing as you reported I get this (see the attached screenshot).

I changed the modules code, which now cleans the cache every time the module is enabled/disabled.

Thanks for the report, and the help.

Some notes about comment #9.

1. Modules that implement meta tags needs already to implement hook_nodewords_info(); from the comment, it seems the module is not implementing such custom hook, which is not true.
2. A hashing code is useful if the code gets as input the original value used to create the hashing code; hashing codes are used to save passwords, and the code that verifies if the entered password is right compares the hashing code of the entered password with the saved hashing code.
   filter.module uses a hashing code because it checks if the text passed to the function has been already filtered, and saved in the cache; it cannot use the text to populate the field cid (which is just 255 characters long), and it uses the MD5 code, which is unique (or it is supposed to be unique) for each input given.
3. To know if a hash code is present, the code should get the original value used to create the hash code; this means the code should do something like this:
   • Ask to the modules the list of the meta tags they implement.
   • Verify if there is already in cache the hash code for the meta tags it gets.
   • If the hash code exists, use the data present in the cache.

   The purpose of the cache is to avoid to ask to the modules the meta tags they implement (which would be useless, when there are no changes in the list of implement meta tags); if the code needs to compare the data returned from the modules with the cached data, it is useless to have cached data.

4. See the previous point.
5. To limit the temporal validity of the cache can be done; differently from the data cached by filter.module, the data cached from nodewords.module are not supposed to change frequently.
6. Even limiting the validity of the cached data to one day, a module could be disabled before one day is passed; if such hooks would be removed, the cache would contain stale data, if one module would be enabled / disabled.

If a module adds an additional tag the cache is not automatically updated.

The module that adds additional meta tags should also call cache_clear_all('tags_info', 'cache_nodewords').

the current tag_info implementation is broken and does not automatically refresh if modules defining tags for nodewords are enabled/disabled

The actual implementations of hook_enable() and hook_disable() do call cache_clear_all('tags_info', 'cache_nodewords'). Also, when a table cache contains stale data, the table is cleared out; no module updates a cache table when it clears the cache (re-populating the cache table is normally done when the data that should be in the cache are requested, which happens in a different time than when the cache is cleared).

As you are suggesting to remove the cache used by the module, then the issue title should be changed to Remove the cache tables used by the module.

I would suggest to use the hashing of the array to solve the invalidation issues.

Hashing code cannot be used, when you don't have the original value used to create the hash code.

filter.module uses a hash code because it knows the text that needs to be passed through the input format, and it checks if it saved the result in cache. The cache entry is named after the text to cache, and the function uses md5() because the database field is limited to 255 characters (while the text can be longer than 255 characters).

Similar code cannot be used from nodewords.module, which doesn't know the name of the meta tag without to first query the modules that implement meta tags.

function check_markup($text, $format = FILTER_FORMAT_DEFAULT, $check = TRUE) {
  // When $check = TRUE, do an access check on $format.
  if (isset($text) && (!$check || filter_access($format))) {
    $format = filter_resolve_format($format);

    // Check for a cached version of this piece of text.
    $cache_id = $format .':'. md5($text);
    if ($cached = cache_get($cache_id, 'cache_filter')) {
      return $cached->data;
    }
    // ...
}

I removed the cache, which was not avoiding any database access (except for the entry pages, which contained a limited number of entries).

As there are not been comments reporting any cache issues (which could not exist anymore because the relative code has been removed), I am marking this report as fixed.