Alzabo::MySQL - Alzabo and MySQL
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.
- 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.
- 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
"function" or
"select" methods of either table or
schema objects.
- 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.
- 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.
- All of this may lead to apparent inconsistencies when using the with the
"Alzabo::Create::Schema->sync_backend"
or
"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
"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.
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
"begin_work()" method, whether or not this
will actually do anything.
- Column constraints are treated as column attributes.
- Foreign key constraints are not generated when generating SQL for a MySQL
schema. This will probably change in the future.
These can be specified as a table attribute.