Data Store Overview

This document describes Action Scheduler’s store abstraction (ActionScheduler_Store) and how to select or extend stores.

Purpose of the Store Abstraction

Action Scheduler uses a data store layer to persist actions and provide a consistent query/claim interface. The abstraction lives in classes/abstracts/ActionScheduler_Store.php and is implemented by concrete stores:

  • ActionScheduler_DBStore (custom tables, default in current versions)
  • ActionScheduler_wpPostStore (legacy WP posts)
  • ActionScheduler_HybridStore (migration bridge between two stores)

The store exposes a unified API for:

  • saving actions
  • fetching and querying actions
  • managing claims
  • updating statuses and timestamps
  • cancellation and deletion

Store Selection

The store is chosen via the ActionScheduler_Store::instance() factory:

  • Default class: ActionScheduler_wpPostStore
  • Filter: action_scheduler_store_class
php
$class = apply_filters( 'action_scheduler_store_class', ActionScheduler_Store::DEFAULT_CLASS );

This is the primary integration point for custom store implementations.

Abstract Store API (Public Methods)

All concrete stores must implement (or inherit) the following public methods:

  • save_action( ActionScheduler_Action $action, ?DateTime $scheduled_date = null )
  • fetch_action( $action_id )
  • find_action( $hook, $params = array() )
  • query_actions( $query = array(), $query_type = 'select' )
  • query_action( $query )
  • action_counts()
  • extra_action_counts()
  • cancel_action( $action_id )
  • delete_action( $action_id )
  • get_date( $action_id )
  • stake_claim( $max_actions = 10, ?DateTime $before_date = null, $hooks = array(), $group = '' )
  • get_claim_count()
  • release_claim( ActionScheduler_ActionClaim $claim )
  • unclaim_action( $action_id )
  • mark_failure( $action_id )
  • log_execution( $action_id )
  • mark_complete( $action_id )
  • get_status( $action_id )
  • get_claim_id( $action_id )
  • find_actions_by_claim_id( $claim_id )
  • cancel_actions_by_hook( $hook )
  • cancel_actions_by_group( $group )
  • get_status_labels()
  • has_pending_actions_due()
  • init()
  • mark_migrated( $action_id )

Notes:

  • find_action() and query_action() are convenience wrappers that call query_actions().
  • extra_action_counts() adds a “past-due” count and is filterable.

Filters and Actions Used by Stores

Store Selection

  • action_scheduler_store_class
    • Controls which class ActionScheduler_Store::instance() instantiates.

Counts

  • Controls which class ActionScheduler_Store::instance() instantiates.

Bulk Cancel

  • Controls which class ActionScheduler_Store::instance() instantiates.

Store Implementations at a Glance

ActionScheduler_DBStore

Custom tables implementation. See db-store.md.

ActionScheduler_wpPostStore

Legacy store that persists actions as a custom post type plus meta and taxonomy. See post-store.md.

ActionScheduler_HybridStore

Read-through migration store that moves actions from the legacy store to the custom-table store on demand. See hybrid-store.md.

Data Persistence Responsibilities

Stores are responsible for translating an ActionScheduler_Action to and from the underlying storage:

  • action_scheduler_extra_action_counts
    • Filter to add extra counts to extra_action_counts().

Action logging uses a separate abstraction, ActionScheduler_Logger, with its own factory and filter. See logger.md.