Bumping version to 1.61
[dbsrgits/SQL-Translator.git] / lib / SQL / Translator / Producer / TT / Table.pm
index 1b9ec68..9e5c1de 100644 (file)
@@ -48,10 +48,10 @@ allows you to write the result for each table to a separate file.
 It needs one additional producer_arg of C<tt_table> which is the file
 name of the template to use.  This template will be passed a template
 var of C<table>, which is the current
-L<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 L<schema> as a shortcut to the
-L<SQL::Translator::Producer::Schema> for the table and C<translator>,
+L<SQL::Translator::Schema::Table> table we are producing,
+which you can then use to walk the schema via the methods documented
+in that module. You also get C<schema> as a shortcut to the
+L<SQL::Translator::Schema> for the table and C<translator>,
 the L<SQL::Translator> object for this parse in case you want to get
 access to any of the options etc set here.
 
@@ -82,7 +82,7 @@ If you set C<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).
-Its also particularly good for code generation where you want to
+It's also particularly good for code generation where you want to
 produce a class file per table.
 
 =head1 OPTIONS
@@ -157,7 +157,7 @@ use strict;
 use warnings;
 
 our ( $DEBUG, @EXPORT_OK );
-our $VERSION = '1.59';
+our $VERSION = '1.61';
 $DEBUG   = 0 unless defined $DEBUG;
 
 use File::Path;
@@ -296,7 +296,8 @@ implicitly through use in a project but need some proper tests).
 
 - Better hooks for filename generation.
 
-- Integrate with L<TT::Base> and L<TTSchema>.
+- Integrate with L<TT::Base|SQL::Translator::Producer::TT::Base> and
+  L<TTSchema|SQL::Translator::Producer::TTSchema>.
 
 =head1 SEE ALSO