This is another take (PoC/SPIKE) on EZP-29584

When there is multilingual Content with the same name in more than one translation, when the name is changed, only path for one translation is properly archived (a.k.a. "historized"), meaning proper HTTP redirect 30X will happen only for one translation.

It is caused by an architecture issue in a ezurlalias_ml database table. It has Primary Key set to (parent, text_md5), which excludes possibility to set more than one state (e.g. archived, not archived) for more than one language if the name is the same.

The more BC safe idea from EZP-29584 is going to be considered as the solution here.

Solution under investigation

The idea is to move archived auto-generated entries to a separate new table and align with that Gateway internal implementation:

CREATE TABLE ibexa_urlalias_archive (
  node_id int NOT NULL,
  alias_redirects boolean NOT NULL DEFAULT false,
  is_always_available boolean NOT NULL DEFAULT false,
  language_id bigint NOT NULL,
  link_id int NOT NULL DEFAULT 0,
  parent_id int NOT NULL DEFAULT 0,
  text longtext NOT NULL,
  text_md5 char(32) NOT NULL,
  PRIMARY KEY (language_id, parent_id, text_md5),
  FOREIGN KEY ibexa_urlalias_archive_node (node_id) REFERENCES ezcontentobject_tree (node_id),
  FOREIGN KEY ibexa_urlalias_archive_lang (language_id) REFERENCES ezcontent_language (id),
  FOREIGN KEY ibexa_urlalias_archive_link (link_id) REFERENCES ezurlalias_ml (id),
  FOREIGN KEY ibexa_urlalias_archive_parent (parent_id) REFERENCES ezurlalias_ml (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

The advantage of this solution is possibility of introducing it in a BC-safe way, though some simple data migration (e.g either by SQL upgrade script or some upgrade command) would be recommended.
The current risk we see ATM is ability to uniformly handle mixed hierarchy data, where some parts of the path are archived and some are not. This is what needs to be investigated.