/ 
DBIO-MySQL-0.900004
/ DBIO::MySQL::Diff::View

NAME

DBIO::MySQL::Diff::View - Diff operations for MySQL/MariaDB views

VERSION

version 0.900004

DESCRIPTION

Represents a view-level diff operation: CREATE VIEW or DROP VIEW.

DBIO::MySQL::Introspect::Tables lists a view under tables with kind => 'view', and the diff used to take it for a table: a view only the schema declares became a CREATE TABLE, one only the database has became a DROP TABLE (the server refuses it on a view, error 1051), and its columns were diffed as a table's. A view is created as a view and removed as a view, and no table, column or index operation is ever written for one -- DBIO::MySQL::Diff::Table, DBIO::MySQL::Diff::Column and DBIO::MySQL::Diff::Index leave every entry of kind view alone ("without_views").

What counts as a changed view

The definition is the view_definition of the table entry, which the introspection reads from information_schema.views. The server does not hand back what was written: it rewrites the SELECT (every name in backticks and qualified with its table, AS for every column, parentheses around a WHERE on MySQL, its own spelling of the functions) and puts the name of the database in front of every table. It is the same rewrite for every view, so two views of one meaning written alike compare equal, and the introspection takes the own database name out (DBIO::MySQL::Introspect::Tables), because a model built from a temporary database, as the target of an upgrade is, would otherwise never equal the live one. Whitespace is set aside in the comparison. A model that holds no definition on either side has nothing to compare, and the view counts as unchanged.

A view that is written differently but that the server rewrites to the same statement is not a changed view; the server's rewrite is the definition of "the same" here.

MySQL has ALTER VIEW and CREATE OR REPLACE VIEW, MariaDB too, but the two statements are the pair every driver of the family writes for it, so a changed definition is a drop followed by a create.

ATTRIBUTES

view_name

The name of the view.

view_info

The view's entry in the tables section of the model it comes from: the target's for a create, the source's for a drop. A create needs its view_definition.

replaced

True on the drop of a changed view: the view is not removed, the create that follows puts it back with its new definition. "classify" in DBIO::Diff::Base counts such a drop as changing, not destructive.

METHODS

is_view

DBIO::MySQL::Diff::View::is_view($table_info)

True for a table entry of kind view.

without_views

my ($tables, @sections) = DBIO::MySQL::Diff::View::without_views(
    $tables, $columns, $indexes);

The tables section of a model without its views, and each further section (columns, indexes, foreign_keys: hashrefs keyed by table name) without the entries of those views. The arguments are not changed.

model_without_views

my $model = DBIO::MySQL::Diff::View::model_without_views($model);

A copy of a whole model with the views taken out of every section.

diff

my @ops = DBIO::MySQL::Diff::View->diff($source_tables, $target_tables);

Compares the tables sections of two models, looking at the entries of kind view only. Returns a drop op for a view only the source has, a create op for a view only the target has, and both, drop first and marked "replaced", for a view whose definition has changed. All drops come first, then all creates, each in dependency order ("The order of the views"). DBIO::MySQL::Diff puts every drop at the head of the diff and every create at its end, and keeps the order within each.

as_sql

DROP VIEW `name`; or CREATE VIEW `name` AS definition;, the name quoted with "quote_ident" in DBIO::MySQL::Identifier. A create whose "view_info" holds no view_definition throws, naming the view: a view cannot be written from its columns.

summary

+ view: name or - view: name. It never throws, for an op "as_sql" refuses.

The order of the views

A view can read another view, and the server refuses CREATE VIEW for one that reads a view that does not exist (error 1146). So:

  • the create ops are in the order "order_views" in DBIO::MySQL::DDL gives for the views being created, read from the definitions of the target: a view after the views it reads, otherwise by name. It is the function "install_ddl" in DBIO::MySQL::DDL orders its CREATE VIEW statements with, so the install and the upgrade write one order.

  • the drop ops are the reverse of that order for the views being dropped, read from the definitions of the source: a view before the views it reads.

  • a view that reads a view being replaced (a drop and a create of a changed definition), directly or through other views, is replaced with it, although its own definition did not change. Measured on MySQL 8.0.30 and MariaDB 11.8.9: the server lets a view be dropped that others read; the reader answers with error 1356 (invalid references) until a view of the name exists again, and if the new definition lost a column the reader reads, it stays broken and says so only when it is queried. The reader is dropped before the view it reads and created after it, in the order above, so the server checks it against the new definition when the diff is applied: a reader that no longer fits fails there, loudly. Its drop is marked "replaced". A view that reads only views that stay as they are is not touched.

  • views that read each other in a cycle are refused with a DBIO::Exception that names them; no operation is returned.

How a definition is read for what it reads, and what is not recognised, is in "view_reads" in DBIO::MySQL::DDL.

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.