5

In Drupal8, what purpose does the key_value_expire table data serve? Can that be excluded from a database backup?

I ask because, during development, I backup the database using "drush sql-dump --ordered-dump" and exclude tables like "cache*", but after making a few minor content changes in a node/page (did not create a revision) and re-dumping the database, git diff is saying that all of the data in the key_value_expire table changed.

key_value_expire is one of the larger tables in Drupal, in terms of # of rows of data, so it will balloon the storage requirements for Git if the data in this table changes completely for every minor change on the site.

Also, is there a detailed explanation of the functionality/purpose of each Drupal table?

Thank you very much in advance.

6

Beside the form cache and the update status the key_value_expire table is mainly used by the private and shared temp store. There you find a good explanation what the purpose of this data is:

class PrivateTempStore

Stores and retrieves temporary data for a given owner.

A PrivateTempStore can be used to make temporary, non-cache data available across requests. The data for the PrivateTempStore is stored in one key/value collection. PrivateTempStore data expires automatically after a given timeframe.

The PrivateTempStore is different from a cache, because the data in it is not yet saved permanently and so it cannot be rebuilt. Typically, the PrivateTempStore might be used to store work in progress that is later saved permanently elsewhere, e.g. autosave data, multistep forms, or in-progress changes to complex configuration that are not ready to be saved.

The PrivateTempStore differs from the SharedTempStore in that all keys are ensured to be unique for a particular user and users can never share data. If you want to be able to share data between users or use it for locking, use \Drupal\user\SharedTempStore.

Reference: https://api.drupal.org/api/drupal/core%21modules%21user%21src%21SharedTempStore.php/class/SharedTempStore/8.2.x https://api.drupal.org/api/drupal/core!modules!user!src!PrivateTempStore.php/class/PrivateTempStore/8.2.x

  • 2
    To summarize, yes it is not cache and can't just be invalidated on a live site, but there is nothing in there that you need to persist and you probably also don't need to back it up, if you can live with e.g. losing unsaved views changes and so on if you have to restore – Berdir Dec 2 '16 at 19:49
  • Thanks for your helpful replies 4k4 and Berdir. Do you have links to the Drupal documentation about the key_value_expire table and PrivateTempStore? Thanks again! – kvjava1 Dec 3 '16 at 2:39
  • 1
    Can you also omit key_value table from backup/source control? Thanks again. – kvjava1 Dec 3 '16 at 4:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.