Magento 2: ¿Cuál es la diferencia entre row_id y entity_id en las tablas% _entity?

En Magento 1, no había una columna llamada row_iden las tablas de entidades, sólo tenía el entity_id:

CREATE TABLE `catalog_category_entity` (
  `entity_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Entity ID',
  `entity_type_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Entity Type ID',
  `attribute_set_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Attriute Set ID',
  `parent_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'Parent Category ID',
  `created_at` timestamp NULL DEFAULT NULL COMMENT 'Creation Time',
  `updated_at` timestamp NULL DEFAULT NULL COMMENT 'Update Time',
  `path` varchar(255) NOT NULL COMMENT 'Tree Path',
  `position` int(11) NOT NULL COMMENT 'Position',
  `level` int(11) NOT NULL DEFAULT '0' COMMENT 'Tree Level',
  `children_count` int(11) NOT NULL COMMENT 'Child Count',
  PRIMARY KEY (`entity_id`),
  KEY `IDX_CATALOG_CATEGORY_ENTITY_LEVEL` (`level`),
  KEY `IDX_CATALOG_CATEGORY_ENTITY_PATH_ENTITY_ID` (`path`,`entity_id`)
) ENGINE=InnoDB AUTO_INCREMENT=943 DEFAULT CHARSET=utf8 COMMENT='Catalog Category Table'

Pero Magento 2 introduce un concepto del row_idque se convierte en la clave principal de una entidad, que parece tener algo que ver con el control de versiones del comentario:

CREATE TABLE `catalog_category_entity` (
  `row_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Version Id',
  `entity_id` int(10) unsigned NOT NULL COMMENT 'Entity Id',
  `created_in` bigint(20) unsigned NOT NULL COMMENT 'Update Id',
  `updated_in` bigint(20) unsigned NOT NULL COMMENT 'Next Update Id',
  `attribute_set_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Attriute Set ID',
  `parent_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'Parent Category ID',
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Creation Time',
  `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 'Update Time',
  `path` varchar(255) NOT NULL COMMENT 'Tree Path',
  `position` int(11) NOT NULL COMMENT 'Position',
  `level` int(11) NOT NULL DEFAULT '0' COMMENT 'Tree Level',
  `children_count` int(11) NOT NULL COMMENT 'Child Count',
  PRIMARY KEY (`row_id`),
  KEY `CATALOG_CATEGORY_ENTITY_LEVEL` (`level`),
  KEY `CATALOG_CATEGORY_ENTITY_CREATED_IN` (`created_in`),
  KEY `CATALOG_CATEGORY_ENTITY_UPDATED_IN` (`updated_in`),
  KEY `CAT_CTGR_ENTT_ENTT_ID_SEQUENCE_CAT_CTGR_SEQUENCE_VAL` (`entity_id`),
  CONSTRAINT `CAT_CTGR_ENTT_ENTT_ID_SEQUENCE_CAT_CTGR_SEQUENCE_VAL` FOREIGN KEY (`entity_id`) REFERENCES `sequence_catalog_category` (`sequence_value`) ON DELETE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=956 DEFAULT CHARSET=utf8 COMMENT='Catalog Category Table'

Esto es lo que hizo cierta incertidumbre al querer unirse EAV campos como ahora los tipos se refieren al row_idlugar de la entity_id:

CREATE TABLE `catalog_category_entity_varchar` (
  `value_id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Value ID',
  `attribute_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Attribute ID',
  `store_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Store ID',
  `row_id` int(10) unsigned NOT NULL COMMENT 'Version Id',
  `value` varchar(255) DEFAULT NULL COMMENT 'Value',
  PRIMARY KEY (`value_id`),
  UNIQUE KEY `CATALOG_CATEGORY_ENTITY_VARCHAR_ENTITY_ID_ATTRIBUTE_ID_STORE_ID` (`row_id`,`attribute_id`,`store_id`),
  KEY `CATALOG_CATEGORY_ENTITY_VARCHAR_ENTITY_ID` (`row_id`),
  KEY `CATALOG_CATEGORY_ENTITY_VARCHAR_ATTRIBUTE_ID` (`attribute_id`),
  KEY `CATALOG_CATEGORY_ENTITY_VARCHAR_STORE_ID` (`store_id`),
  CONSTRAINT `CATALOG_CATEGORY_ENTITY_VARCHAR_STORE_ID_STORE_STORE_ID` FOREIGN KEY (`store_id`) REFERENCES `store` (`store_id`) ON DELETE CASCADE,
  CONSTRAINT `CAT_CTGR_ENTT_VCHR_ATTR_ID_EAV_ATTR_ATTR_ID` FOREIGN KEY (`attribute_id`) REFERENCES `eav_attribute` (`attribute_id`) ON DELETE CASCADE,
  CONSTRAINT `CAT_CTGR_ENTT_VCHR_ROW_ID_CAT_CTGR_ENTT_ROW_ID` FOREIGN KEY (`row_id`) REFERENCES `catalog_category_entity` (`row_id`) ON DELETE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=266383 DEFAULT CHARSET=utf8 COMMENT='Catalog Category Varchar Attribute Backend Table'

Actualmente en la tabla de entidades row_idy entity_idson los mismos:

select row_id, entity_id from catalog_category_entity limit 3;        
+--------+-----------+
| row_id | entity_id |
+--------+-----------+
|      1 |         1 |
|      2 |         2 |
|      3 |         3 |
+--------+-----------+
3 rows in set (0.00 sec)

No estoy seguro de las circunstancias en las que row_idva a cambiar y el impacto que esto tendrá sobre el sistema de Magento, he buscado documentación sobre esta característica, pero no puedo encontrar ninguna.

Quiero saber lo siguiente:

• ¿Puede la misma entidad tener múltiples row_ids?
  • Si es así, ¿cómo se define la entidad activa?
  • Si no, ¿cuál es el mecanismo que Magento utiliza para actualizarlos?
• ¿Cuál es el uso principal de esta función y hay alguna documentación?
  • http://devdocs.magento.com/guides/v2.1/extension-dev-guide/staging/Staging.html

Por lo que he encontrado en este, row_ides el identificador de la fila, mientras que entity_ides la entidad real.

Hay situaciones en las que una Actualización programada está configurada para ejecutarse durante un período fijo y, en este caso, se crea una fila completamente nueva para asociarse con sus variantes eav_attributey puede retenerla entity_idmientras se emite una nueva. row_idLuego, row_idse cambia a nueva entidad temporal y luego de vuelta al original una vez que se complete la programación.

Puede haber otros casos de uso en los que hacen uso de esto, este fue uno de los que presencié e ilumina cómo se puede usar.

El entity_idse usa solo en la versión Magento 2 EE. Se utiliza como un índice definido al catalog_category_entityseñalar sequence_catalog_category.

Las tablas de secuencia, en general, se utilizan para la función de división de la base de datos.

Diría que el objetivo es mantener la compatibilidad con Magento 1. Cuando necesite migrar datos de m1 a m2, necesitará esa relación.