Skip to content

Technical Database

Daniel Neto edited this page Oct 29, 2026 · 1 revision

Technical database and caching

Audience: developers and advanced administrators. Baseline reviewed: 2026-10-29.

Persistence interfaces

The core database layer is sqlDAL in objects/mysql_dal.php. Its main read interface is readSql($preparedStatement, $formats = '', $values = [], $refreshCache = false); writes use writeSql(). Format strings and bound values describe query parameters. Entity classes commonly extend ObjectYPT from objects/Object.php.

The initial schema lives in install/database.sql; core upgrades live in updatedb/. Plugin schema is defined by the relevant plugin's installer/migrations and can be independently versioned. The source reference index lists DDL table references and links to the actual historical SQL.

Tables and installed state

Core domains include videos, users, categories, comments, plugin registry and site configuration. Exact columns must be verified in the actual schema/migrations and current object class. The existence of a class or an old CREATE TABLE statement does not prove the installation has completed its migrations.

Use read-only schema/count/record checks to establish a baseline. Preserve table prefixes and deployment-specific database names. A production database is not a clean installation fixture.

Cache layers and stale reads

Layer Characteristic Diagnostic consequence
sqlDAL::readSql() request cache Reuses the same SQL/values in a request A later write does not automatically invalidate that earlier read result
ObjectYPT and cache handlers Cache domain-object/list results Follow the specific cache key and invalidation behavior
Cache plugin/persistent DB cache Can queue invalidations A write can succeed before visible invalidation is processed
Page cache Can serve a rendered response Correct database state does not alone prove the browser is receiving a fresh page

Reads that must observe their own writes can require the explicit refresh argument. In CacheHandler::deleteCache(), scheduled invalidation is the default. Cache::executeEveryMinute() processes queued prefixes and expiration. Without working scheduled execution, stale data can survive longer than a developer expects.

Source examples such as category-list cache versioning demonstrate why a fresh fingerprint can be necessary when deletion is asynchronous. Do not repeatedly clear unrelated cache layers without identifying which one produced the result.

Transactions and payments

Ordinary transaction helpers live in objects/functionsMySQL.php. Payment processing additionally uses a dedicated wallet transaction/lock path and savepoints. A database write, wallet credit and access-plan fulfillment have different commit semantics; see payments.

Migration diagnostics

Compare the current schema version, required migration, SQL error log and actual table/column definition. Keep a distinction between a skipped migration, an error during execution, a mismatched plugin package and a stale application read. Do not edit a released migration or delete a production table as routine recovery.

Clone this wiki locally