---
name: "Alzabo::MySQL"
section: "3pm"
platform: "linux"
package: "libalzabo-perl"
version: "0.92-6"
release: "Debian 13 (Trixie)"
platforms: ["linux"]
url: "https://new.carta.tech/Alzabo::MySQL"
---

# Alzabo::MySQL(3pm)

Alzabo and MySQL

## NAME

Alzabo::MySQL - Alzabo and MySQL

## 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.

### 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.

### Transactions

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.