Please do not remove InnoDB support

[motin]

Issue #1 was incorrectly fixed imho. This is a solution that works for both:

CREATE TABLE `news_version` (
  `version` int(11) NOT NULL AUTO_INCREMENT,
  `id` int(11) NOT NULL,
  `title` varchar(255) NOT NULL,
  `content` text NOT NULL,
  `author_id` int(11) NOT NULL,
  `version_comment` varchar(255) NOT NULL,
  `created_by` varchar(255) NOT NULL,
  `created_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`version`)
);

If "version" auto-increments, it will always be unique, thus there is no need for a composite primary key.
If it does not always increment (through special insert logic or similar), there is no need for auto-increment.

Ergo, do not use a composite primary key.

[Darkheir]

Sorry for the (very) late answer!

The problem if we don't use a composite key is that version will be update on each insert.
So if:

• We create news 1 => version will be 1 in news_version
• We modify news 1 => version will be 2 in news_version
• We create news 2 => version will be 3 in news_version

So we'll endup with a news first version equal to 3 and that is not something we want!

[motin]

Ok, you want to keep the version number semantic by only auto incrementing it within records with the same id.
Any plans on re-adding InnoDB support in another way, like using a unique index over "id, version" instead of a composite primary key, together with manually incrementing the version number (as opposed to relying on the db engine to do it for you)?