Provided by: libalzabo-perl_0.92-4_all bug


       Alzabo::MySQL - Alzabo and MySQL


       This documentation is about what special support Alzabo has for MySQL, as well as what is

       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.

   Reverse Engineering
       ·   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.

   Constraints and Foreign Keys
       ·   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.

   Table Types
           These can be specified as a table attribute.