/ 
DBIO-MySQL-0.900004
/ DBIO::MySQL::Test::Conformance

NAME

DBIO::MySQL::Test::Conformance - Answers the shared conformance case table for the MySQL and MariaDB driver

VERSION

version 0.900004

SYNOPSIS

use DBIO::MySQL::Test::Conformance;
DBIO::MySQL::Test::Conformance->run('DDL');
done_testing;

DESCRIPTION

The driver's half of the shared case table of DBIO::Test::Conformance (core ADR 0060). Core owns the cases and the runner; this class says how to reach a MySQL or MariaDB server, how to install a declaration into it through DBIO::MySQL::Deploy, and how to read a fact back through DBIO::MySQL::Introspect.

The server is the one DBIO_TEST_MYSQL_DSN, DBIO_TEST_MYSQL_USER and DBIO_TEST_MYSQL_PASS name; without the DSN (or without a DBD) only the declarations are checked. A run needs an account that may create databases: "diff" in DBIO::MySQL::Deploy builds its target in a temporary one. MySQL and MariaDB are two servers behind one set of variables, and the class is run once against each; what holds on one only is declared per server by "conformance_refusals", which asks the server which it is.

The namespace of a case is a database of its own. Every case gets a database dbio_cf_<pid>_<n>, created by "conformance_connect" over a connection of its own; the DSN of the case names it, so the diff -- which compares the whole of the current database -- sees nothing but the case. "conformance_namespace" refuses a database that is not empty, and "conformance_cleanup" drops a database only when this run created it.

The class names no storage class and never decides the driver, the DSN does (see "conformance_connect").

METHODS

conformance_live_available

True when DBIO_TEST_MYSQL_DSN is set and the DBD it names loads (DBD::mysql or DBD::MariaDB).

conformance_connect

Creates the database of the case, loads the MySQL schema component into the case's schema class and connects to that database. storage_type is not set by this class beyond what the component does: the declared driver is MySQL's, the DSN only says which DBD reaches it.

Over DBD::mysql the connection asks for mysql_enable_utf8mb4 => 1, in the attribute hash -- the DSN is ignored for it. Without it the DBD returns text as the bytes it stores and the cases that bind characters read bytes back. The driver keeps that default, since an application may hold bytes in a text column on purpose; one that wants characters connects like this. DBD::MariaDB takes characters without being asked and refuses the attribute.

conformance_connect_attributes

Connect attributes added to those of "conformance_connect", as a list of pairs; none here. A subclass that runs the Bind list over the future_io transport returns async => 'future_io'.

conformance_namespace

Returns the name of the case's database as the token for "conformance_cleanup", after checking that it holds no table and no view. A database that is not empty ends the case.

conformance_install

Installs the declaration with $schema->deploy, the public entry point, which hands over to "install" in DBIO::MySQL::Deploy.

A source named database.table (ddl-qualified-source-name) is made in a database that is not the case's, so the class takes care of it: a table of that name that is on the server already is not the run's to use or drop, and ends the case; one that is not is marked, and "conformance_cleanup" drops it. The database itself is never created or dropped.

conformance_cleanup

Drops the database of the token when "conformance_connect" of this run created it, the tables "conformance_install" marked in other databases, and disconnects. Nothing else is dropped: without a mark no database is touched. The drop goes through a connection of its own.

conformance_diff_is_empty

True when "diff" in DBIO::MySQL::Deploy of the installed database against the same declaration has no changes.

conformance_upgrade

Connects the target schema class to the database of the installed one and runs "upgrade" in DBIO::MySQL::Deploy -- the public entry point -- through it. The connection is made like "conformance_connect" makes it, to the same database; the target class takes over the namespace (and the duty to drop it) of the installed one, since the runner hands only the returned schema to "conformance_cleanup". The upgrade runs with allow_destructive => 1: the cases of the table are about what the diff does (a dropped column, a changed type), the guard that holds a destructive diff back has its own cases (diff-deploy-destructive-guard, run through "conformance_deploy"). A refusal of the diff is thrown from here as it came; the database then stays with the installed schema, whose cleanup drops it.

conformance_deploy

The deploy object over the target schema, for the deploy cases of the Diff list (table version 4): the target class is connected to the database of the installed one exactly as "conformance_upgrade" connects it, and takes over its namespace and the duty to drop it. Returns DBIO::MySQL::Deploy->new(schema => $to); the runner calls apply and upgrade on it.

conformance_answered_through

The table versions the answers were written against, per area: { DDL => 2, Diff => 4, Bind => 1 }, every list as it stands (version 2 of the DDL list splits the type-size case into ddl-type-size-char and ddl-type-size-bit, version 2 of the Diff list splits U13 into diff-constraint-changed and diff-fk-action-changed, both answered right on MySQL and MariaDB).

Version 3 of the Diff list replaces diff-column-dropped-with-index by diff-indexed-column-dropped; it runs.

Version 4 of the Diff list adds the deploy cases (diff-deploy-*): they run through "conformance_deploy", which hands the runner the DBIO::MySQL::Deploy object, so apply and upgrade are the base class's.

conformance_server_is_mariadb

True when the server behind DBIO_TEST_MYSQL_DSN is a MariaDB, by its SELECT VERSION(); asked once.

conformance_refusals

Two refusals are declared, and a third only on a server that lacks something.

diff-column-added-not-null-populated and diff-not-null-over-nulls are refused by the engine's rules, before the first statement, by "_refuse_unfillable" in DBIO::MySQL::Deploy, naming table and column: there is no value for the rows a table holds when a NOT NULL column without a default is added (the server would invent the implicit default of the type), and a NOT NULL over a NULL cannot hold (strict: error 1138; otherwise the NULL is silently rewritten). Maintainer decision 2026-10-25, as in the SQLite and PostgreSQL drivers.

ddl-qualified-source-name writes the table t into the database other (table('other.t')). The driver creates no database, and the case does not either, so the answer depends on the server: where a database other exists, the table is made in it and the case runs through, read back by "conformance_fact"; where it does not, "install" in DBIO::MySQL::Deploy refuses, naming table and database, before its first statement, and the case is declared a server refusal. Which of the two holds is asked of the server (_database_exists), read only, in the manner of the Oracle driver's check of its user other.

conformance_fact

Reads one fact through DBIO::MySQL::Introspect, of the database of the case; the vocabulary is the one of "Facts" in DBIO::Test::Conformance. table_in_namespace asks the namespace named, a database.

SEE ALSO

AUTHOR

DBIO & DBIx::Class Authors

COPYRIGHT AND LICENSE

Copyright (C) 2026 DBIO Authors Portions Copyright (C) 2005-2025 DBIx::Class Authors Based on DBIx::Class, heavily modified.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.