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
|
