=head2 filters
-Set or retreive the filters to run over the schema during the
+Set or retrieve the filters to run over the schema during the
translation, before the producer creates its output. Filters are sub
routines called, in order, with the schema object to filter as the 1st
arg and a hash of options (passed as a list) for the rest of the args.
sub diff_table_fields {
my ($self, $src_table, $tar_table) = @_;
- # List of ones ew've renamed from so we dont drop them
+ # List of ones we've renamed from so we don't drop them
my %renamed_source_fields;
for my $tar_table_field ( $tar_table->get_fields ) {
my ($a_name, undef, $b_name, undef) = ( %$a, %$b );
$a_name cmp $b_name;
};
- # Need to sort the options so we dont get supruious diffs.
+ # Need to sort the options so we don't get spurious diffs.
my (@src_opts, @tar_opts);
@src_opts = sort $cmp $src_table->options;
@tar_opts = sort $cmp $tar_table->options;
=head1 DESCRIPTION
Takes two input SQL::Translator::Schemas (or SQL files) and produces ALTER
-statments to make them the same
+statements to make them the same
=head1 SNYOPSIS
C<preprocess_schema> is called by the Diff code to allow the producer to
normalize any data it needs to first. For example, the MySQL producer uses
-this method to ensure that FK contraint names are unique.
+this method to ensure that FK constraint names are unique.
Basicaly any changes that need to be made to produce the SQL file for the
schema should be done here, so that a diff between a parsed SQL file and (say)
$schema->drop_table($gtbl);
}
- # Add globalis to tables
+ # Add globals to tables
foreach my $tbl ( $schema->get_tables ) {
foreach my $new_fld ( @global_fields ) {
$ sqlt -f xSV --fs ',' -t SQLite foo.csv > foo-sqlite.sql
-Additionally, there is a non-SQL represenation of relational schemas namely
+Additionally, there is a non-SQL representation of relational schemas namely
XML. Additionally, the only XML supported is our own version; however, it
would be fairly easy to add an XML parser for something like the TorqueDB
(http://db.apache.org/torque/) project. The actual parsing of XML should be
parsed schema if you need to perform repeated conversions. For
example, as part of a build process the author converts a MySQL schema
first to YAML, then to PostgreSQL, Oracle, SQLite and Sybase.
-Additionally, a variety of documention in HTML and images is produced.
+Additionally, a variety of documentation in HTML and images is produced.
This can be accomplished like so:
$ sqlt -f MySQL -t YAML schema-mysql.sql > schema.yaml
1;
# -------------------------------------------------------------------
-# All wholsome food is caught without a net or a trap.
+# All wholesome food is caught without a net or a trap.
# William Blake
# -------------------------------------------------------------------
=head2 default_value
Leave the attribute out all together to use the default in L<Schema::Field>.
-Use empty quotes or 'EMPTY_STRING' for a zero lenth string. 'NULL' for an
+Use empty quotes or 'EMPTY_STRING' for a zero length string. 'NULL' for an
explicit null (currently sets default_value to undef in the
Schema::Field obj).
=head1 LEGACY FORMAT
-The previous version of the SQLFairy XML allowed the attributes of the the
+The previous version of the SQLFairy XML allowed the attributes of the
schema objects to be written as either xml attributes or as data elements, in
any combination. While this allows for lots of flexibility in writing the XML
the result is a great many possible XML formats, not so good for DTD writing,
XPathing etc! So we have moved to a fixed version described in
L<SQL::Translator::Producer::XML::SQLFairy>.
-This version of the parser will still parse the old formats and emmit warnings
+This version of the parser will still parse the old formats and emit warnings
when it sees them being used but they should be considered B<heavily
depreciated>.
};
#
- # Primary key may have a differenct accessor method name
+ # Primary key may have a different accessor method name
#
# if ( my $constraint = $table->primary_key ) {
# my $field = ( $constraint->fields )[0];
Currently you will get one class (with the a table
stereotype) generated per table in the schema. The fields are added as
attributes of the classes and their datatypes set. It doesn't currently set any
-of the relationships. It doesn't do any layout, all the classses are in one big
+of the relationships. It doesn't do any layout, all the classes are in one big
stack. However it is still useful as you can use the layout tools in Dia to
automatically arrange them horizontally or vertically.
=head1 TODO
-* Add the foriegn keys from the schema as UML relations.
+* Add the foreign keys from the schema as UML relations.
* Layout the classes.
=item * show_fields (DEFAULT: true)
-If set to a true value, the names of the colums in a table will
+If set to a true value, the names of the columns in a table will
be displayed in each table's node
=item * show_fk_only
Currently you will get one class (with the a table
stereotype) generated per table in the schema. The fields are added as
attributes of the classes and their datatypes set. It doesn't currently set any
-of the relationships. It doesn't do any layout, all the classses are in one big
+of the relationships. It doesn't do any layout, all the classes are in one big
stack. However it is still useful as you can use the layout tools in Dia to
automatically arrange them horizontally or vertically.
=item B<table.mysql_charset>, B<table.mysql_collate>
-Set the tables default charater set and collation order.
+Set the tables default character set and collation order.
=item B<field.mysql_charset>, B<field.mysql_collate>
-Set the fields charater set and collation order.
+Set the fields character set and collation order.
=back
);
#
-# Column types that do not support lenth attribute
+# Column types that do not support length attribute
#
my @no_length_attr = qw/
date time timestamp datetime year
# Normalize constraint names here.
my $c_name = $c->name;
- # Give the constraint a name if it doesn't have one, so it doens't feel
+ # Give the constraint a name if it doesn't have one, so it doesn't feel
# left out
$c_name = $table->name . '_fk' unless length $c_name;
my ($table, $diff_hash, $options) = @_;
# InnoDB has an issue with dropping and re-adding a FK constraint under the
- # name in a single alter statment, see: http://bugs.mysql.com/bug.php?id=13741
+ # name in a single alter statement, see: http://bugs.mysql.com/bug.php?id=13741
#
# We have to work round this.
$to_field->name)
if ( !defined $new_default && defined $old_default );
- # add geometry column and contraints
+ # add geometry column and constraints
push @out, add_geometry_column($to_field) if is_geometry($to_field);
push @out, add_geometry_constraints($to_field) if is_geometry($to_field);
my %temp_table_fields;
do {
local $table->{name} = $table_name . '_temp_alter';
- # We only want the table - dont care about indexes on tmp table
+ # We only want the table - don't care about indexes on tmp table
my ($table_sql) = create_table($table, {no_comments => 1, temporary_table => 1});
push @sql,$table_sql;
source, or an L<IO::Handle>. See L<Template> for details, as the return from
this is passed on to it's C<produce> method.
-The default implimentation uses the producer arg C<ttfile> as a filename to read
+The default implementation uses the producer arg C<ttfile> as a filename to read
the template from. If the arg isn't there it will look for a C<__DATA__> section
in the class, reading it as template source if found. Returns undef if both
these fail, causing the produce call to fail with a 'no template!' error.
=head2 tt_default_vars
Return a hash-ref of the default vars given to the template.
-You wouldn't normally over-ride this, just inherit the default implimentation,
+You wouldn't normally over-ride this, just inherit the default implementation,
to get the C<translator> & C<schema> variables, then over-ride L<tt_vars> to add
your own.
WARNING: This method is Experimental so may change!
Called with the L<SQL::Translator::Schema> object and should return one (it
-doesn't have to be the same one) that will become the C<schema> varibale used
+doesn't have to be the same one) that will become the C<schema> variable used
in the template.
Gets called from tt_default_vars.
=head2 schema
-Return the L<SQL::Translator::Schema> we are translating. This is equivilent
+Return the L<SQL::Translator::Schema> we are translating. This is equivalent
to C<< $tt_producer->translator->schema >>.
=head2 run
=head2 args
Util wrapper method around C<< TT::Base->translator->producer_args >> for
-(mostley) readonly access to the producer args. How it works depends on the
+(mostly) readonly access to the producer args. How it works depends on the
number of arguments you give it and the context.
No args - Return hashref (the actual hash in Translator) or hash of args.
See F<t/data/template/table.tt> for a more complete example.
-You can also set any of the options used to initiallize the Template
+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.
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 particulary good for code generation where you want to
+Its also particularly good for code generation where you want to
produce a class file per table.
=head1 OPTIONS
B<replace> - Over-write the existing file with the new one, clobbering
anything already there.
-B<skip> - Leave the origional file as it was and don't write the new
+B<skip> - Leave the original file as it was and don't write the new
version anywhere.
B<die> - Die with an existing file error.
-B<insert> - Insert the generated output into the file bewteen a set of
+B<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).
}
}
- my ($dir) = $file =~ m!^(.*)/!; # Want greedy, eveything before the last /
+ my ($dir) = $file =~ m!^(.*)/!; # Want greedy, everything before the last /
if ( $dir and not -d $dir and $pargs->{mk_file_dir} ) { mkpath($dir); }
debug "Writing to $file\n";
my $cstart = $pargs->{insert_comment_start} || "SQLF_INSERT_START";
my $cend = $pargs->{insert_comment_end} || "SQLF_INSERT_END";
- # Slurp in the origional file
+ # Slurp in the original file
open ( FILE, "<", "$file") or die "Error opening file $file : $!\n";
local $/ = undef;
my $orig = <FILE>;
=head1 TODO
- Some tests for the various on exists options (they have been tested
-implicitley through use in a project but need some proper tests).
+implicitly through use in a project but need some proper tests).
- More docs on code generation strategies.
The template will also get the set of extra variables given as a hashref via the
C<tt_vars> producer arg.
-You can set any of the options used to initiallize the Template object by
+You can set any of the options used to initialize the Template object by
adding a tt_conf producer_arg. See Template Toolkit docs for details of
the options.
(Note that the old style of passing this config directly in the producer args
Previous versions of SQL::Translator included an XML producer, but the
namespace has since been further subdivided. Therefore, this module is
-now just just an alias to the XML::SQLFairy producer.
+now just an alias to the XML::SQLFairy producer.
=head1 SEE ALSO
=head1 LEGACY FORMAT
-The previous version of the SQLFairy XML allowed the attributes of the the
+The previous version of the SQLFairy XML allowed the attributes of the
schema objects to be written as either xml attributes or as data elements, in
any combination. The old producer could produce attribute only or data element
only versions. While this allowed for lots of flexibility in writing the XML
#
# Takes an XML::Writer, Schema::* object and list of method names
-# and writes the obect out as XML. All methods values are written as attributes
+# and writes the object out as XML. All methods values are written as attributes
# except for the methods listed in @MAP_AS_ELEMENTS which get written as child
# data elements.
#
my @meths = @{ $args{'methods'} };
my $empty_tag = 0;
- # Use array to ensure consistant (ie not hash) ordering of attribs
+ # Use array to ensure consistent (ie not hash) ordering of attribs
# The order comes from the meths list passed in.
my @tags;
my @attr;
=head2 make_natural_joins
-Creates foriegn key relationships among like-named fields in different
+Creates foreign key relationships among like-named fields in different
tables. Accepts the following arguments:
=over 4
=item * join_pk_only
-A True or False argument which determins whether or not to perform
+A True or False argument which determines whether or not to perform
the joins from primary keys to fields of the same name in other tables
=item * skip_fields
Get or set whether the constraint is deferrable. If not defined,
then returns "1." The argument is evaluated by Perl for True or
-False, so the following are eqivalent:
+False, so the following are equivalent:
$deferrable = $field->deferrable(0);
$deferrable = $field->deferrable('');
use DBI qw(:sql_types);
-# Mapping from string to sql contstant
+# Mapping from string to sql constant
our %type_mapping = (
integer => SQL_INTEGER,
int => SQL_INTEGER,
smallint => SQL_SMALLINT,
- bigint => 9999, # DBI doesn't export a constatn for this. Le suck
+ bigint => 9999, # DBI doesn't export a constant for this. Le suck
double => SQL_DOUBLE,
=head2 extra
-Get or set the field's "extra" attibutes (e.g., "ZEROFILL" for MySQL).
+Get or set the field's "extra" attributes (e.g., "ZEROFILL" for MySQL).
Accepts a hash(ref) of name/value pairs to store; returns a hash.
$field->extra( qualifier => 'ZEROFILL' );
Get or set whether the field can be null. If not defined, then
returns "1" (assumes the field can be null). The argument is evaluated
-by Perl for True or False, so the following are eqivalent:
+by Perl for True or False, so the following are equivalent:
$is_nullable = $field->is_nullable(0);
$is_nullable = $field->is_nullable('');
=head2 extra
-Get or set the objects "extra" attibutes (e.g., "ZEROFILL" for MySQL fields).
+Get or set the objects "extra" attributes (e.g., "ZEROFILL" for MySQL fields).
Call with no args to get all the extra data.
Call with a single name arg to get the value of the named extra attribute,
returned as a scalar. Call with a hash or hashref to set extra attributes.
Returns the C<SQL::Translator::Schema::Constraint> object representing
the primary key.
-These are eqivalent:
+These are equivalent:
$table->primary_key('id');
$table->primary_key(['name']);
=head1 DESCRIPTIONS
-This module exports fuctions that return coderefs suitable for L<Moo>
+This module exports functions that return coderefs suitable for L<Moo>
C<isa> type checks.
Errors are reported using L<SQL::Translator::Utils/throw>.
=item Test skipping
-As the test subs wrap up lots of tests in one call you can't skip idividual
+As the test subs wrap up lots of tests in one call you can't skip individual
tests only whole sets e.g. a whole table or field.
We could add skip_* items to the test hashes to allow per test skips. e.g.
field called "name" to be considered a foreign key, so you could
include it in the "skip" option, and all fields called "name" will be
excluded from natural joins. A more efficient method, however, might
-be to simply deduce the foriegn keys from primary keys to other fields
+be to simply deduce the foreign keys from primary keys to other fields
named the same in other tables. Use the "natural-join-pk" option
to achieve this.
field called "name" to be considered a foreign key, so you could
include it in the "skip" option, and all fields called "name" will be
excluded from natural joins. A more efficient method, however, might
-be to simply deduce the foriegn keys from primary keys to other fields
+be to simply deduce the foreign keys from primary keys to other fields
named the same in other tables. Use the "natural-join-pk" option
-to acheive this.
+to achieve this.
If the schema defines foreign keys, then the graph produced will be
directed showing the direction of the relationship. If the foreign
projects / dbsrgits/SQL-Translator.git / commitdiff