Blog

10.07.2020 // Renée Bäcker

Gregor und ich haben einige CPAN-Module. Wir wollen hier an dieser Stelle auch immer wieder auf wichtige Neuerungen in unseren Modulen aufmerksam machen.

In den letzten Wochen habe ich vermehrt an MySQL::Workbench::Parser und MySQL::Workbench::DBIC gearbeitet um die Abbildung von Views zu unterstützen.

In der Workbench können ganz einfach Views hinzugefügt werden. In der Konfiguration muss nur das SQL-Statement angegeben werden, wie der View aufgebaut werden soll:

Der Vorteil der Workbench liegt darin, dass man mit Kunden und auch untereinander einfach die Workbench-Datei austauschen kann und man etwas grafisches vor Augen hat wenn man das Datenbankschema bespricht.

Wir nutzen die Workbench und die beiden Module in verschiedenen Projekten um DBIx::Class-Klassen für den Zugriff auf die Datenbank zu erzeugen.

Mit einem kleinen Skript lässt sich der Perl-Code ganz einfach generieren:

use Mojo::File qw(curfile);

use MySQL::Workbench::DBIC;

my $foo = MySQL::Workbench::DBIC->new(
    file                    => curfile->sibling('view.mwb')->to_string,
    output_path             => curfile->sibling('lib')->to_string,
    namespace               => 'Project::DB',
    schema_name             => 'Schema',
    column_details          => 1, # default 1
);

$foo->create_schema;

print sprintf "Version %s of DB created\n", $foo->version;

Damit werden dann folgende Dateien erstellt:

$ tree lib
lib
└── Project
    └── DB
        ├── Schema
        │   └── Result
        │       ├── table1.pm
        │       └── table2.pm
        └── Schema.pm

table1.pm und table2.pm repräsentieren die entsprechenden Tabellen (siehe Abbildung weiter oben) und mit den neuen Versionen von MySQL::Workbench::Parser und MySQL::Workbench::DBIC werden die Klassen view1.pm und view2.pm erzeugt.

Die Klassen sehen wie folgt aus:

package Project::DB::Schema::Result::view1;

# ABSTRACT: Result class for view1

use strict;
use warnings;
use base qw(DBIx::Class);

our $VERSION = 0.05;

__PACKAGE__->load_components( qw/PK::Auto Core/ );
__PACKAGE__->table_class('DBIx::Class::ResultSource::View');
__PACKAGE__->table( 'view1' );

__PACKAGE__->result_source_instance->view_definition(
    "CREATE VIEW `view1` AS
    SELECT 
        cidr, col2
    FROM
        table1;"
);

__PACKAGE__->result_source_instance->deploy_depends_on(
    ["Project::DB::Schema::Result::table1"]
);

__PACKAGE__->add_columns(
    cidr => {
        data_type          => 'INT',
        is_numeric         => 1,
    },
    col2 => {
        data_type          => 'VARCHAR',
        is_nullable        => 1,
        size               => 45,
    },

);

Die entscheidenden Zeilen sind

__PACKAGE__->table_class('DBIx::Class::ResultSource::View');

__PACKAGE__->result_source_instance->view_definition(
    "CREATE VIEW `view1` AS
    SELECT 
        cidr, col2
    FROM
        table1;"
);

Als Klasse, wird hier DBIx::Class::ResultSource::View verwendet, das extra für Views existiert. Anschließend erfolgt die SQL-Definition, wie sie in der Workbench eingetragen wurde.

Hier wird absichtlich kein

__PACKAGE__->result_source_instance->is_virtual(1);

verwendet, weil die Views tatsächlich in der Datenbank angelegt werden sollen. Mit is_virtual(1) wird der View rein virtuell behandelt.

Über diese Module habe ich übrigens im letzten Jahr auf dem Deutschen Perl-Workshop einen Vortrag gehalten:

Die Code-Beispiele liegen wieder im Gitlab-Repository.

---

Permalink: /2020-07-17-cpan-updates