/usr/share/perl5/Alzabo/MySQL.pod is in libalzabo-perl 0.92-4.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 | =pod
=head1 NAME
Alzabo::MySQL - Alzabo and MySQL
=head1 DESCRIPTION
This documentation is about what special support Alzabo has for MySQL,
as well as what is lacking.
MySQL support is based on the 3.23.* release series, with some support
for features that are starting to appear in the 4.0.* releases.
Earlier versions of MySQL will probably work with Alzabo, though
Alzabo cannot magically make these releases support new features like
fulltext indexes.
=head2 Indexes
=over 4
=item *
Alzabo supports the ability to specify prefixes when adding an index.
Prefixes are required when attempting to index any sort of text or
blob column.
=item *
Alzabo supports the creation of fulltext indexes and their use in
SELECT and WHERE clauses. This includes the ability to get back the
score given for a match as part of a select, using the C<function> or
C<select> methods of either table or schema objects.
=back
=head2 Reverse Engineering
=over 4
=item *
When reverse engineering a schema, Alzabo knows that MySQL has
"default defaults" for certain column types. For example, if a DATE
column is specified as NOT NULL but is not assigned a default, MySQL
gives this column a default of '0000-00-00'.
Because Alzabo knows about this, it will ignore these defaults when
reverse engineering an RDBMS.
=item *
Similarly, Alzabo knows that MySQL assigns default "lengths" to many
column types. For example, if given INTEGER as a column type, MySQL
will convert this to INTEGER(11) or INTEGER(10), depending on the
version of MySQL being used.
Again, Alzabo ignores these lengths when reverse engineering a schema.
=item *
All of this may lead to apparent inconsistencies when using the with
the L<C<< Alzabo::Create::Schema->sync_backend
>>|Alzabo::Create::Schema/"sync_backend"> or L<C<<
Alzabo::Create::Schema->sync_backend_sql
>>|Alzabo::Create::Schema/"sync_backend_sql"> methods. If you are
using this feature from the web based schema creator, you will see
that even immediately after running the C<sync_backend()> method,
Alzabo may still think there are differences between the two schemas.
This is not a problem, as running the SQL Alzabo generates will not
actually change your database.
=back
=head2 Transactions
=over 4
Alzabo will try to use transactions whenever appropriate.
Unfortunately, there is no way to determine whether or not a given
table supports transactions so Alzabo simply calls DBI's
C<begin_work()> method, whether or not this will actually do anything.
=back
=head2 Constraints and Foreign Keys
=over 4
=item *
Column constraints are treated as column attributes.
=item *
Foreign key constraints are not generated when generating SQL for a
MySQL schema. This will probably change in the future.
=back
=head2 Table Types
=over 4
These can be specified as a table attribute.
=back
=cut
|