archivable behavior generates duplicate INDEX migrations

[felixgeyer]

After adding the archivable behavior to one of our table definitions, the generated migration is invalid because it includes the same CREATE INDEX statement twice:

CREATE INDEX "spy_quote_request_archive_i_3e1efe" ON "spy_quote_request_archive" ("quote_request_reference");

BEGIN;

CREATE TABLE "spy_quote_request_archive"
(
    "id_quote_request" INTEGER NOT NULL,
    "fk_company_user" INTEGER NOT NULL,
    "created_at" TIMESTAMP,
    "is_latest_version_visible" BOOLEAN DEFAULT 't',
    "quote_request_reference" VARCHAR(255) NOT NULL,
    "status" VARCHAR(255),
    "uuid" VARCHAR(255),
    "valid_until" TIMESTAMP,
    "updated_at" TIMESTAMP,
    "archived_at" TIMESTAMP,
    PRIMARY KEY ("id_quote_request")
);

CREATE INDEX "spy_quote_request_archive_i_b0cd64" ON "spy_quote_request_archive" ("fk_company_user");

CREATE INDEX "spy_quote_request_archive_i_3e1efe" ON "spy_quote_request_archive" ("quote_request_reference");

CREATE INDEX "spy_quote_request_archive_i_d402b5" ON "spy_quote_request_archive" ("status");

CREATE INDEX "spy_quote_request_archive_i_e57848" ON "spy_quote_request_archive" ("valid_until","status");

CREATE INDEX "spy_quote_request_archive_i_d404ac" ON "spy_quote_request_archive" ("created_at");

CREATE INDEX "spy_quote_request_archive_i_36c49e" ON "spy_quote_request_archive" ("uuid");

CREATE INDEX "spy_quote_request_archive_i_3e1efe" ON "spy_quote_request_archive" ("quote_request_reference");

COMMIT;

This is our table schema that uses the archivable behavior:

    <table name="spy_quote_request">
        <column name="id_quote_request" required="true" type="INTEGER" autoIncrement="true" primaryKey="true"/>
        <column name="fk_company_user" type="INTEGER" required="true"/>
        <column name="created_at" type="TIMESTAMP"/>
        <column name="is_latest_version_visible" type="BOOLEAN" default="true"/>
        <column name="quote_request_reference" type="VARCHAR" size="255" required="true"/>
        <column name="status" type="VARCHAR" size="255"/>
        <column name="uuid" required="false" type="VARCHAR" size="255"/>
        <column name="valid_until" type="TIMESTAMP" required="false"/>
        <foreign-key name="spy_quote_request-fk_company_user" foreignTable="spy_company_user" phpName="CompanyUser">
            <reference local="fk_company_user" foreign="id_company_user"/>
        </foreign-key>
        <index name="spy_quote_request-fk_company_user">
            <index-column name="fk_company_user"/>
        </index>
        <index name="spy_quote_request-quote_request_reference">
            <index-column name="quote_request_reference"/>
        </index>
        <index name="spy_quote_request-status">
            <index-column name="status"/>
        </index>
        <index name="spy_quote_request-valid_until-status">
            <index-column name="valid_until"/>
            <index-column name="status"/>
        </index>
        <index name="spy_quote_request-created_at">
            <index-column name="created_at"/>
        </index>
        <unique name="spy_quote_request-uuid">
            <unique-column name="uuid"/>
        </unique>
        <unique name="spy_quote_request-reference">
            <unique-column name="quote_request_reference"/>
        </unique>
        <id-method-parameter value="spy_quote_request_pk_seq"/>
        <behavior name="uuid">
            <parameter name="key_columns" value="quote_request_reference"/>
        </behavior>
        <behavior name="timestampable"/>
        <behavior name="archivable"/>
    </table>

The column quote_request_reference both should be unique and explicitly get an index (which is redundant, but is no issue when not using the archivable behavior). I assume that this is the problem when using the archivable behavior.

Our Propel version: 2.0.0-beta1