NAME

       SQL::Translator::Producer::TT::Table -
           Produces output using the Template Toolkit from a SQL schema, per table.

SYNOPSIS

         # Normal STDOUT version
         #
         my $translator     = SQL::Translator->new(
             from           => 'MySQL',
             filename       => 'foo_schema.sql',
             to             => 'TT::Table',
             producer_args  => {
                 tt_table     => 'foo_table.tt',
             },
         );
         print $translator->translate;

         # To generate a file per table
         #
         my $translator     = SQL::Translator->new(
             from           => 'MySQL',
             filename       => 'foo_schema.sql',
             to             => 'TT::Table',
             producer_args  => {
                 tt_table       => 'foo_table.tt.html',
                 mk_files      => 1,
                 mk_files_base => "./doc/tables",
                 mk_file_ext   => ".html",
                 on_exists     => "replace",
             },
         );
         #
         # ./doc/tables/ now contains the templated tables as $tablename.html
         #

DESCRIPTION

       Produces schema output using a given Template Tookit template, processing that template
       for each table in the schema. Optionally allows you to write the result for each table to
       a separate file.

       It needs one additional producer_arg of "tt_table" which is the file name of the template
       to use.  This template will be passed a template var of "table", which is the current
       SQL::Translator::Producer::Table table we are producing, which you can then use to walk
       the schema via the methods documented in that module. You also get schema as a shortcut to
       the SQL::Translator::Producer::Schema for the table and "translator", the SQL::Translator
       object for this parse in case you want to get access to any of the options etc set here.

       Here's a brief example of what the template could look like:

         [% table.name %]
         ================
         [% FOREACH field = table.get_fields %]
             [% field.name %]   [% field.data_type %]([% field.size %])
         [% END -%]

       See t/data/template/table.tt for a more complete example.

       You can also set any of the options used to initialize the Template object by adding them
       to your producer_args. See Template Toolkit docs for details of the options.

         $translator          = SQL::Translator->new(
             to               => 'TT',
             producer_args    => {
                 ttfile       => 'foo_template.tt',
                 INCLUDE_PATH => '/foo/templates/tt',
                 INTERPOLATE  => 1,
             },
         );

       If you set "mk_files" and its additional options the producer will write a separate file
       for each table in the schema. This is useful for producing things like HTML documentation
       where every table gets its own page (you could also use TTSchema producer to add an index
       page).  It's also particularly good for code generation where you want to produce a class
       file per table.

OPTIONS

       tt_table
           File name of the template to run for each table.

       mk_files
           Set to true to output a file for each table in the schema (as well as returning the
           whole lot back to the Translalor and hence STDOUT). The file will be named after the
           table, with the optional "mk_files_ext" added and placed in the directory
           "mk_files_base".

       mk_files_ext
           Extension (without the dot) to add to the filename when using mk_files.

       mk_files_base = DIR
           Dir to build the table files into when using mk_files. Defaults to the current
           directory.

       mk_file_dir
           Set true and if the file needs to written to a directory that doesn't exist, it will
           be created first.

       on_exists [Default:replace]
           What to do if we are running with mk_files and a file already exists where we want to
           write our output. One of "skip", "die", "replace", "insert".  The default is die.

           replace - Over-write the existing file with the new one, clobbering anything already
           there.

           skip - Leave the original file as it was and don't write the new version anywhere.

           die - Die with an existing file error.

           insert - Insert the generated output into the file between a set of special comments
           (defined by the following options.) Any code between the comments will be overwritten
           (ie the results from a previous produce) but the rest of the file is left alone (your
           custom code).  This is particularly useful for code generation as it allows you to
           generate schema derived code and then add your own custom code to the file.  Then when
           the schema changes you just re-produce to insert the new code.

       insert_comment_start
           The comment to look for in the file when on_exists is "insert". Default is "SQLF
           INSERT START". Must appear on it own line, with only whitespace either side, to be
           recognised.

       insert_comment_end
           The end comment to look for in the file when on_exists is "insert".  Default is "SQLF
           INSERT END". Must appear on it own line, with only whitespace either side, to be
           recognised.

AUTHOR

       Mark Addison <grommit@users.sourceforge.net>.

TODO

       - Some tests for the various on exists options (they have been tested implicitly through
       use in a project but need some proper tests).

       - More docs on code generation strategies.

       - Better hooks for filename generation.

       - Integrate with TT::Base and TTSchema.

SEE ALSO

       SQL::Translator.