device:03
  :   	ˆl–ß=¿J*C]Šq@µq–®JbÑ¿¿„¿a–Ãa¾”*j"TâÆÁpBSÿÄ *K    	=head1 NAME

DBI::DBD::SqlEngine::HowTo - Guide to create DBI::DBD::SqlEngine based driver

=head1 SYNOPSIS

  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

=head1 DESCRIPTION

This document provides a step-by-step guide, how to create a new
C<DBI::DBD::SqlEngine> based DBD. It expects that you carefully read the
L<DBI> documentation and that you're familiar with L<DBI::DBD> and had
read and understood L<DBD::ExampleP>.

This document addresses experienced developers who are really sure that
they need to invest time when writing a new DBI Driver. Writing a DBI
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.

Those who are still reading, should be able to sing the rules of
L<DBI::DBD/CREATING A NEW DRIVER>.

=head1 CREATING DRIVER CLASSES

Do you have an entry in DBI's DBD registry? DBI::DBD::SqlEngine expect
having a unique prefix for every driver class in inheritance chain.

It's easy to get a prefix - just drop the DBI team a note
(L<DBI/GETTING_HELP>). If you want for some reason hide your work, take
a look at L<Class::Method::Modifiers> how to wrap a private prefix method
around existing C<driver_prefix>.

For this guide, a prefix of C<foo_> is assumed.

=head2 Sample Skeleton

    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;

Tiny, eh? And all you have now is a DBD named foo which will is able to
deal with temporary tables, as long as you use L<SQL::Statement>. In
L<DBI::SQL::Nano> environments, this DBD can do nothing.

=head2 Deal with own attributes

Before we start doing usable stuff with our DBI driver, we need to think
about what we want to do and how we want to do it.

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 DBD is running "behind" a L<DBD::Gofer> proxy).

How come the attributes into the DBD and how are they fetchable by the
user? Good question, but you should know because you've read the L<DBI>
documentation.

C<DBI::DBD::SqlEngine::db::FETCH> and C<DBI::DBD::SqlEngine::db::STORE>
taking care for you - all they need to know is which attribute names
are valid and mutable or immutable. Tell them by adding
C<init_valid_attributes> to your db class:

    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,	# ..