Db final class

The SQL modes WordPress turns off for its session (wpdb's incompatible modes): strictness and the modes that change what queries mean.

Whether a transaction this door opened is still open, so a nested call joins it instead of starting another.

Promoted from the constructor.

Promoted from the constructor.

The most a column of a MySQL type holds, as wpdb::get_col_length answers: characters for char and varchar, bytes for the binary, blob and text types; false for any other type.

The connection the request being answered speaks through: its runtime's own, so nothing deep in a render can reach a connection belonging to another request. With no runtime (the command line, the unit suite) it is the process's own connection.

This is the one place in the core that asks the runtime anything; the alternative is a database door threaded through every renderer, and the seam is here until that threading is done.

The one connection for this process, opened from wp-config's constants on first use, its session without the incompatible modes, as WordPress's own connection is (a plugin's insert that leaves out a text column then succeeds, as it does there).

The session's modes: the server's, less the reference's incompatible ones and NO_BACKSLASH_ESCAPES, which the engine's own literal escaping (Query\Sql) relies on being off. Plugins see only the reference's list (incompatible_sql_modes).

A comma-separated SQL mode list without the incompatible ones (any case).

Sets this session's SQL modes, never NO_BACKSLASH_ESCAPES: the engine's literals escape quotes with a backslash (Query\Sql), which that mode would turn into a plain character, so a set_sql_mode() asking for it gets every other mode it named.

The underlying mysqli handle, for the facade's wpdb.

A value escaped for direct interpolation into SQL, for callers that build their own statements.

The table prefix from wp-config.

`posts` becomes `wp_posts`; the prefix comes from wp-config.php.

Every row of a prepared query, as associative arrays.

The first row of a prepared query, or null.

The first column of the first row, or null when there is no row.

Runs a write and returns the affected row count.

Asks to be told whenever a write statement names a table (Content\RowCache drops what it kept from it).

Tells the listeners of every table a write statement names, whichever door ran it (this one, or the facade's wpdb for plugin code). A name that merely contains another (wp_postmeta for posts) is not it.

Rewrites every "?" whose parameter is a list into that many placeholders, and flattens the values to match, so "IN (?)" becomes "IN (?, ?, ?)". An empty list becomes NULL, which nothing is IN, so a caller that means "everything" when the list is empty says so itself.

Runs a unit of work as one transaction: everything the closure writes lands, or none of it does. The closure's return value is passed back.

A transaction already open is joined rather than nested, since the storage engine has no nested transactions; the outermost call is the one that commits. A table that cannot do transactions (MyISAM, which no WordPress core table uses) silently keeps each write, which is the behaviour there was before this existed.

The id the last INSERT produced.

One option's stored value, or null when it is unset; home and siteurl answer to WP_HOME and WP_SITEURL. Once the runtime boots, the read is its option store's (the autoloaded list, wp_cache's options group), so the engine's own reads cost no query each, as get_option()'s don't.

Where option reads come from from now on: the runtime's option store, or null for the row itself.

What wp-config.php sets for an option, or null: WP_HOME and WP_SITEURL, when defined, stand for home and siteurl on every read, as on the reference (_config_wp_home), without a trailing slash.

One option's row as stored, whatever wp-config.php says, or null when it is unset.