We started Cerb4 with the idea of supporting MySQL, PostgreSQL, MSSQL, Oracle, etc. As development has progressed, we’ve hit several issues where our database functionality needs won’t abstract or overlap effectively.

The major benefits of Cerb4 standardizing on MySQL 4.1+:

• Fulltext searching: Right now we’re implementing database-driven functionality where our supported platforms (MySQL and PostgreSQL, at the moment) overlap. On text searching, this currently centers on basic SQL-92 “LIKE” syntax searches. The downsides here are pretty obvious; there’s no boolean support, wildcard searching is grossly inefficient when looking for multiple words and the order of keywords must be precise. The ideal situation is to have the full feature set of MySQL’s FULLTEXT index type, which, while not perfect, opens up a more Google-like syntax that’s much more useful than what we’re currently doing.
• Internationalization: It’s much faster and cleaner to be able to depend on MySQL’s encodings and multibyte behavior than to abstract how each platform approaches i18n. MySQL has its own tricks too, like “SET NAMES utf-8;” being issued per connection to ensure the client and server are handling multibyte encoding the same way.
• Sub-queries/Foreign Keys/Cascades/Joins: With day-to-day functionality we haven’t had much of a problem avoiding sub-queries or foreign keys for MySQL 3.23’s benefit. However, to support this rather old version of MySQL we lose the ability to be efficient in database patches and maintenance tasks. While not exclusive benefits of MySQL 4.1+, cascaded deletes on foreign keys, sub-queries and joins in UPDATE/DELETE would make patching and maintenance much more efficient. We end up with a lot of N+1 queries presently, where if ‘N’ is based on a table like ‘ticket’ it may end up around 1 million repeats of a query. This ends up clashing with the default PHP execution time of 30 seconds (which is fine for rendering a typical page, and an eternal pain for upgrading/maintenance tasks in PHP when the execution time can’t be overloaded at script level).
• Transactions: Another needless concession to MySQL 3.23, without transactions we have a much harder time making sure partial data isn’t written to the database — especially while parsing tickets. Transactions ensure everything is successful or none of the changes are applied. We’ve always needed this, and MySQL 3.23 support has always been in the way.

All of these issues contribute to the speed of development.

That’s the case to be made on our end. Making this change would unstick several big feature requests, that are far more important to us than the marketing bulletin of ‘database independence’. We’d really like to hear from you if this change would be a problem for you.

Please take a moment to vote on this issue in the forums.