1SQL::Translator::ProducUesre:r:TCTo:n:tTraibbluet(e3d)PSeQrLl::DTorcaunmselnattaotri:o:nProducer::TT::Table(3)
2
6 SQL::Translator::Producer::TT::Table -
7 Produces output using the Template Toolkit from a SQL schema, per
8 table.
9
11 # Normal STDOUT version
12 #
13 my $translator = SQL::Translator->new(
14 from => 'MySQL',
15 filename => 'foo_schema.sql',
16 to => 'TT::Table',
17 producer_args => {
18 tt_table => 'foo_table.tt',
19 },
20 );
21 print $translator->translate;
22 # To generate a file per table
24 #
25 my $translator = SQL::Translator->new(
26 from => 'MySQL',
27 filename => 'foo_schema.sql',
28 to => 'TT::Table',
29 producer_args => {
30 tt_table => 'foo_table.tt.html',
31 mk_files => 1,
32 mk_files_base => "./doc/tables",
33 mk_file_ext => ".html",
34 on_exists => "replace",
35 },
36 );
37 #
38 # ./doc/tables/ now contains the templated tables as $tablename.html
39 #
40
42 Produces schema output using a given Template Tookit template,
43 processing that template for each table in the schema. Optionally
44 allows you to write the result for each table to a separate file.
45 It needs one additional producer_arg of "tt_table" which is the file
47 name of the template to use. This template will be passed a template
48 var of "table", which is the current SQL::Translator::Schema::Table
49 table we are producing, which you can then use to walk the schema via
50 the methods documented in that module. You also get "schema" as a
51 shortcut to the SQL::Translator::Schema for the table and "translator",
52 the SQL::Translator object for this parse in case you want to get
53 access to any of the options etc set here.
54 Here's a brief example of what the template could look like:
56 [% table.name %]
58 ================
59 [% FOREACH field = table.get_fields %]
60 [% field.name %] [% field.data_type %]([% field.size %])
61 [% END -%]
62 See t/data/template/table.tt for a more complete example.
64 You can also set any of the options used to initialize the Template
66 object by adding them to your producer_args. See Template Toolkit docs
67 for details of the options.
68 $translator = SQL::Translator->new(
70 to => 'TT',
71 producer_args => {
72 ttfile => 'foo_template.tt',
73 INCLUDE_PATH => '/foo/templates/tt',
74 INTERPOLATE => 1,
75 },
76 );
77 If you set "mk_files" and its additional options the producer will
79 write a separate file for each table in the schema. This is useful for
80 producing things like HTML documentation where every table gets its own
81 page (you could also use TTSchema producer to add an index page). It's
82 also particularly good for code generation where you want to produce a
83 class file per table.
84
86 tt_table
87 File name of the template to run for each table.
88 mk_files
90 Set to true to output a file for each table in the schema (as well
91 as returning the whole lot back to the Translalor and hence
92 STDOUT). The file will be named after the table, with the optional
93 "mk_files_ext" added and placed in the directory "mk_files_base".
94 mk_files_ext
96 Extension (without the dot) to add to the filename when using
97 mk_files.
98 mk_files_base = DIR
100 Dir to build the table files into when using mk_files. Defaults to
101 the current directory.
102 mk_file_dir
104 Set true and if the file needs to written to a directory that
105 doesn't exist, it will be created first.
106 on_exists [Default:replace]
108 What to do if we are running with mk_files and a file already
109 exists where we want to write our output. One of "skip", "die",
110 "replace", "insert". The default is die.
111 replace - Over-write the existing file with the new one, clobbering
113 anything already there.
114 skip - Leave the original file as it was and don't write the new
116 version anywhere.
117 die - Die with an existing file error.
119 insert - Insert the generated output into the file between a set of
121 special comments (defined by the following options.) Any code
122 between the comments will be overwritten (ie the results from a
123 previous produce) but the rest of the file is left alone (your
124 custom code). This is particularly useful for code generation as
125 it allows you to generate schema derived code and then add your own
126 custom code to the file. Then when the schema changes you just re-
127 produce to insert the new code.
128 insert_comment_start
130 The comment to look for in the file when on_exists is "insert".
131 Default is "SQLF INSERT START". Must appear on it own line, with
132 only whitespace either side, to be recognised.
133 insert_comment_end
135 The end comment to look for in the file when on_exists is "insert".
136 Default is "SQLF INSERT END". Must appear on it own line, with only
137 whitespace either side, to be recognised.
138
140 Mark Addison <grommit@users.sourceforge.net>.
141
143 - Some tests for the various on exists options (they have been tested
144 implicitly through use in a project but need some proper tests).
145 - More docs on code generation strategies.
147 - Better hooks for filename generation.
149 - Integrate with TT::Base and
151 TTSchema.
152
154 SQL::Translator.
155perl v5.30.0 2019-0S7Q-L2:6:Translator::Producer::TT::Table(3)