.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{
.    if \nF \{
.        de IX
.        tm Index:\\$1\t\\n%\t"\\$2"
..
.        if !\nF==2 \{
.            nr % 0
.            nr F 2
.        \}
.    \}
.\}
.rr rF
.\" ========================================================================
.\"
.IX Title "DBI::DBD::SqlEngine::HowTo 3"
.TH DBI::DBD::SqlEngine::HowTo 3 "2016-04-21" "perl v5.16.3" "User Contributed Perl Documentation"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "NAME"
DBI::DBD::SqlEngine::HowTo \- Guide to create DBI::DBD::SqlEngine based driver
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
.Vb 8
\&  perldoc DBI::DBD::SqlEngine::HowTo
\&  perldoc DBI
\&  perldoc DBI::DBD
\&  perldoc DBI::DBD::SqlEngine::Developers
\&  perldoc SQL::Eval
\&  perldoc DBI::DBD::SqlEngine
\&  perldoc DBI::DBD::SqlEngine::HowTo
\&  perldoc SQL::Statement::Embed
.Ve
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
This document provides a step-by-step guide, how to create a new
\&\f(CW\*(C`DBI::DBD::SqlEngine\*(C'\fR based \s-1DBD.\s0 It expects that you carefully read the
\&\s-1DBI\s0 documentation and that you're familiar with \s-1DBI::DBD\s0 and had
read and understood DBD::ExampleP.
.PP
This document addresses experienced developers who are really sure that
they need to invest time when writing a new \s-1DBI\s0 Driver. Writing a \s-1DBI\s0
Driver is neither a weekend project nor an easy job for hobby coders
after work. Expect one or two man-month of time for the first start.
.PP
Those who are still reading, should be able to sing the rules of
\&\*(L"\s-1CREATING A NEW DRIVER\*(R"\s0 in \s-1DBI::DBD\s0.
.SH "CREATING DRIVER CLASSES"
.IX Header "CREATING DRIVER CLASSES"
Do you have an entry in \s-1DBI\s0's \s-1DBD\s0 registry? DBI::DBD::SqlEngine expect
having a unique prefix for every driver class in inheritance chain.
.PP
It's easy to get a prefix \- just drop the \s-1DBI\s0 team a note
(\*(L"\s-1GETTING_HELP\*(R"\s0 in \s-1DBI\s0). If you want for some reason hide your work, take
a look at Class::Method::Modifiers how to wrap a private prefix method
around existing \f(CW\*(C`driver_prefix\*(C'\fR.
.PP
For this guide, a prefix of \f(CW\*(C`foo_\*(C'\fR is assumed.
.SS "Sample Skeleton"
.IX Subsection "Sample Skeleton"
.Vb 1
\&    package DBD::Foo;
\&
\&    use strict;
\&    use warnings;
\&    use vars qw($VERSION);
\&    use base qw(DBI::DBD::SqlEngine);
\&
\&    use DBI ();
\&
\&    $VERSION = "0.001";
\&
\&    package DBD::Foo::dr;
\&
\&    use vars qw(@ISA $imp_data_size);
\&
\&    @ISA = qw(DBI::DBD::SqlEngine::dr);
\&    $imp_data_size = 0;
\&
\&    package DBD::Foo::db;
\&
\&    use vars qw(@ISA $imp_data_size);
\&
\&    @ISA = qw(DBI::DBD::SqlEngine::db);
\&    $imp_data_size = 0;
\&
\&    package DBD::Foo::st;
\&
\&    use vars qw(@ISA $imp_data_size);
\&
\&    @ISA = qw(DBI::DBD::SqlEngine::st);
\&    $imp_data_size = 0;
\&
\&    package DBD::Foo::Statement;
\&
\&    use vars qw(@ISA);
\&
\&    @ISA = qw(DBI::DBD::SqlEngine::Statement);
\&
\&    package DBD::Foo::Table;
\&
\&    use vars qw(@ISA);
\&
\&    @ISA = qw(DBI::DBD::SqlEngine::Table);
\&
\&    1;
.Ve
.PP
Tiny, eh? And all you have now is a \s-1DBD\s0 named foo which will is able to
deal with temporary tables, as long as you use SQL::Statement. In
DBI::SQL::Nano environments, this \s-1DBD\s0 can do nothing.
.SS "Deal with own attributes"
.IX Subsection "Deal with own attributes"
Before we start doing usable stuff with our \s-1DBI\s0 driver, we need to think
about what we want to do and how we want to do it.
.PP
Do we need tunable knobs accessible by users? Do we need status
information? All this is handled in attributes of the database handles (be
careful when your \s-1DBD\s0 is running \*(L"behind\*(R" a DBD::Gofer proxy).
.PP
How come the attributes into the \s-1DBD\s0 and how are they fetchable by the
user? Good question, but you should know because you've read the \s-1DBI\s0
documentation.
.PP
\&\f(CW\*(C`DBI::DBD::SqlEngine::db::FETCH\*(C'\fR and \f(CW\*(C`DBI::DBD::SqlEngine::db::STORE\*(C'\fR
taking care for you \- all they need to know is which attribute names
are valid and mutable or immutable. Tell them by adding
\&\f(CW\*(C`init_valid_attributes\*(C'\fR to your db class:
.PP
.Vb 3
\&    sub init_valid_attributes
\&    {
\&        my $dbh = $_[0];
\&
\&        $dbh\->SUPER::init_valid_attributes ();
\&
\&        $dbh\->{foo_valid_attrs} = {
\&            foo_version         => 1,   # contains version of this driver
\&            foo_valid_attrs     => 1,   # contains the valid attributes of foo drivers
\&            foo_readonly_attrs  => 1,   # contains immutable attributes of foo drivers
\&            foo_bar             => 1,   # contains the bar attribute
\&            foo_baz             => 1,   # contains the baz attribute
\&            foo_manager         => 1,   # contains the manager of the driver instance
\&            foo_manager_type    => 1,   # contains the manager class of the driver instance
\&        };
\&        $dbh\->{foo_readonly_attrs} = {
\&            foo_version         => 1,   # ensure no\-one modifies the driver version
\&            foo_valid_attrs     => 1,   # do not permit one to add more valid attributes ...
\&            foo_readonly_attrs  => 1,   # ... or make the immutable mutable
\&            foo_manager         => 1,   # manager is set internally only
\&        };
\&
\&        return $dbh;
\&    }
.Ve
.PP
Woooho \- but now the user cannot assign new managers? This is intended,
overwrite \f(CW\*(C`STORE\*(C'\fR to handle it!
.PP
.Vb 3
\&    sub STORE ($$$)
\&    {
\&        my ( $dbh, $attrib, $value ) = @_;
\&
\&        $dbh\->SUPER::STORE( $attrib, $value );
\&
\&        # we\*(Aqre still alive, so no exception is thrown ...
\&        # by DBI::DBD::SqlEngine::db::STORE
\&        if ( $attrib eq "foo_manager_type" )
\&        {
\&            $dbh\->{foo_manager} = $dbh\->{foo_manager_type}\->new();
\&            # ... probably correct some states based on the new
\&            # foo_manager_type \- see DBD::Sys for an example
\&        }
\&    }
.Ve
.PP
But ... my driver runs without a manager until someone first assignes
a \f(CW\*(C`foo_manager_type\*(C'\fR. Well, no \- there're two places where you can
initialize defaults:
.PP
.Vb 3
\&    sub init_default_attributes
\&    {
\&        my ($dbh, $phase) = @_;
\&
\&        $dbh\->SUPER::init_default_attributes($phase);
\&
\&        if( 0 == $phase )
\&        {
\&            # init all attributes which have no knowledge about
\&            # user settings from DSN or the attribute hash
\&            $dbh\->{foo_manager_type} = "DBD::Foo::Manager";
\&        }
\&        elsif( 1 == $phase )
\&        {
\&            # init phase with more knowledge from DSN or attribute
\&            # hash
\&            $dbh\->{foo_manager} = $dbh\->{foo_manager_type}\->new();
\&        }
\&
\&        return $dbh;
\&    }
.Ve
.PP
So far we can prevent the users to use our database driver as data
storage for anything and everything. We care only about the real important
stuff for peace on earth and alike attributes. But in fact, the driver
still can't do anything. It can do less than nothing \- meanwhile it's
not a stupid storage area anymore.
.SS "User comfort"
.IX Subsection "User comfort"
\&\f(CW\*(C`DBI::DBD::SqlEngine\*(C'\fR since \f(CW0.05\fR consolidates all persistent meta data
of a table into a single structure stored in \f(CW\*(C`$dbh\->{sql_meta}\*(C'\fR. While
DBI::DBD::SqlEngine provides only readonly access to this structure,
modifications are still allowed.
.PP
Primarily DBI::DBD::SqlEngine provides access via the setters
\&\f(CW\*(C`new_sql_engine_meta\*(C'\fR, \f(CW\*(C`get_sql_engine_meta\*(C'\fR, \f(CW\*(C`get_single_table_meta\*(C'\fR,
\&\f(CW\*(C`set_single_table_meta\*(C'\fR, \f(CW\*(C`set_sql_engine_meta\*(C'\fR and \f(CW\*(C`clear_sql_engine_meta\*(C'\fR.
Those methods are easily accessible by the users via the \f(CW\*(C`$dbh\->func ()\*(C'\fR
interface provided by \s-1DBI.\s0 Well, many users don't feel comfortize when calling
.PP
.Vb 2
\&    # don\*(Aqt require extension for tables cars
\&    $dbh\->func ("cars", "f_ext", ".csv", "set_sql_engine_meta");
.Ve
.PP
DBI::DBD::SqlEngine will inject a method into your driver to increase the
user comfort to allow:
.PP
.Vb 2
\&    # don\*(Aqt require extension for tables cars
\&    $dbh\->foo_set_meta ("cars", "f_ext", ".csv");
.Ve
.PP
Better, but here and there users likes to do:
.PP
.Vb 2
\&    # don\*(Aqt require extension for tables cars
\&    $dbh\->{foo_tables}\->{cars}\->{f_ext} = ".csv";
.Ve
.PP
This interface is provided when derived \s-1DBD\s0's define following in
\&\f(CW\*(C`init_valid_attributes\*(C'\fR (re-capture \*(L"Deal with own attributes\*(R"):
.PP
.Vb 3
\&    sub init_valid_attributes
\&    {
\&        my $dbh = $_[0];
\&
\&        $dbh\->SUPER::init_valid_attributes ();
\&
\&        $dbh\->{foo_valid_attrs} = {
\&            foo_version         => 1,   # contains version of this driver
\&            foo_valid_attrs     => 1,   # contains the valid attributes of foo drivers
\&            foo_readonly_attrs  => 1,   # contains immutable attributes of foo drivers
\&            foo_bar             => 1,   # contains the bar attribute
\&            foo_baz             => 1,   # contains the baz attribute
\&            foo_manager         => 1,   # contains the manager of the driver instance
\&            foo_manager_type    => 1,   # contains the manager class of the driver instance
\&            foo_meta            => 1,   # contains the public interface to modify table meta attributes
\&        };
\&        $dbh\->{foo_readonly_attrs} = {
\&            foo_version         => 1,   # ensure no\-one modifies the driver version
\&            foo_valid_attrs     => 1,   # do not permit one to add more valid attributes ...
\&            foo_readonly_attrs  => 1,   # ... or make the immutable mutable
\&            foo_manager         => 1,   # manager is set internally only
\&            foo_meta            => 1,   # ensure public interface to modify table meta attributes are immutable
\&        };
\&
\&        $dbh\->{foo_meta} = "foo_tables";
\&
\&        return $dbh;
\&    }
.Ve
.PP
This provides a tied hash in \f(CW\*(C`$dbh\->{foo_tables}\*(C'\fR and a tied hash for
each table's meta data in \f(CW\*(C`$dbh\->{foo_tables}\->{$table_name}\*(C'\fR.
Modifications on the table meta attributes are done using the table
methods:
.PP
.Vb 2
\&    sub get_table_meta_attr { ... }
\&    sub set_table_meta_attr { ... }
.Ve
.PP
Both methods can adjust the attribute name for compatibility reasons, e.g.
when former versions of the \s-1DBD\s0 allowed different names to be used for the
same flag:
.PP
.Vb 5
\&    my %compat_map = (
\&                       abc => \*(Aqfoo_abc\*(Aq,
\&                       xyz => \*(Aqfoo_xyz\*(Aq,
\&                     );
\&    _\|_PACKAGE_\|_\->register_compat_map( \e%compat_map );
.Ve
.PP
If any user modification on a meta attribute needs reinitialization of
the meta structure (in case of \f(CW\*(C`DBI::DBD::SqlEngine\*(C'\fR these are the attributes
\&\f(CW\*(C`f_file\*(C'\fR, \f(CW\*(C`f_dir\*(C'\fR, \f(CW\*(C`f_ext\*(C'\fR and \f(CW\*(C`f_lockfile\*(C'\fR), inform DBI::DBD::SqlEngine by
doing
.PP
.Vb 5
\&    my %reset_on_modify = (
\&                            foo_xyz => "foo_bar",
\&                            foo_abc => "foo_bar",
\&                          );
\&    _\|_PACKAGE_\|_\->register_reset_on_modify( \e%reset_on_modify );
.Ve
.PP
The next access to the table meta data will force DBI::DBD::SqlEngine to re-do the
entire meta initialization process.
.PP
Any further action which needs to be taken can handled in
\&\f(CW\*(C`table_meta_attr_changed\*(C'\fR:
.PP
.Vb 6
\&    sub table_meta_attr_changed
\&    {
\&        my ($class, $meta, $attrib, $value) = @_;
\&        ...
\&        $class\->SUPER::table_meta_attr_changed ($meta, $attrib, $value);
\&    }
.Ve
.PP
This is done before the new value is set in \f(CW$meta\fR, so the attribute
changed handler can act depending on the old value.
.SS "Dealing with Tables"
.IX Subsection "Dealing with Tables"
Let's put some life into it \- it's going to be time for it.
.PP
This is a good point where a quick side step to SQL::Statement::Embed
will help to shorten the next paragraph. The documentation in
SQL::Statement::Embed regarding embedding in own \s-1DBD\s0's works pretty
fine with SQL::Statement and DBI::SQL::Nano.
.PP
Second look should go to DBI::DBD::SqlEngine::Developers to get a
picture over the driver part of the table \s-1API.\s0 Usually there isn't much
to do for an easy driver.
.SS "Testing"
.IX Subsection "Testing"
Now you should have your first own \s-1DBD.\s0 Was easy, wasn't it?  But does
it work well? Prove it by writing tests and remember to use
dbd_edit_mm_attribs from \s-1DBI::DBD\s0 to ensure testing even rare cases.
.SH "AUTHOR"
.IX Header "AUTHOR"
This guide is written by Jens Rehsack. DBI::DBD::SqlEngine is written by
Jens Rehsack using code from DBD::File originally written by Jochen
Wiedmann and Jeff Zucker.
.PP
The module DBI::DBD::SqlEngine is currently maintained by
.PP
H.Merijn Brand < h.m.brand at xs4all.nl > and
Jens Rehsack  < rehsack at googlemail.com >
.SH "COPYRIGHT AND LICENSE"
.IX Header "COPYRIGHT AND LICENSE"
Copyright (C) 2010 by H.Merijn Brand & Jens Rehsack
.PP
All rights reserved.
.PP
You may freely distribute and/or modify this module under the terms of
either the \s-1GNU\s0 General Public License (\s-1GPL\s0) or the Artistic License, as
specified in the Perl \s-1README\s0 file.