Magento 2: Quelle est la différence entre row_id et entity_id dans les tables% _entity?

Dans Magento 1, il n'y avait pas de colonne appelée row_iddans les tables d'entités, vous aviez juste 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'

Mais Magento 2 introduit un concept row_idqui devient la clé primaire d'une entité, il semble avoir quelque chose à voir avec la version du commentaire:

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'

Cela me cause une certaine incertitude lorsque je veux rejoindre des champs eav car maintenant les types se réfèrent à la row_idplace de 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'

Actuellement dans la table d'entité row_idet entity_idsont les mêmes:

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)

Je ne sais pas dans quelles circonstances cela row_idva changer et quel impact cela aura sur le système Magento, j'ai cherché de la documentation sur cette fonctionnalité mais je n'en trouve pas.

Je veux savoir ce qui suit:

• La même entité peut-elle avoir plusieurs row_ids?
  • Si oui, comment définit-on l'entité active?
  • Sinon, quel est le mécanisme que Magento utilise pour les mettre à jour.
• Quelle est l'utilisation principale de cette fonctionnalité et existe-t-il une documentation?
  • http://devdocs.magento.com/guides/v2.1/extension-dev-guide/staging/Staging.html

D'après ce que j'ai trouvé sur celui-ci, row_idest l'identifiant de la ligne, tandis que entity_idl'entité réelle.

Il y a des situations où une mise à jour planifiée est réglé pour fonctionner pendant une période déterminée et dans ce cas une nouvelle ligne tout est créé pour associer à la variante de ce eav_attribute(s) et il peut conserver le même entity_idtout en étant publié une nouvelle row_idEnsuite , l' row_idest changé à la nouvelle entité temporaire, puis revenir à l'original une fois le calendrier terminé.

Il peut y avoir d'autres cas d'utilisation où ils utilisent cela, c'est celui dont j'ai été témoin et illustre comment cela peut être utilisé.

Le entity_idest utilisé uniquement dans la version Magento 2 EE. Il est utilisé comme un index défini en catalog_category_entitypointant vers sequence_catalog_category.

Les tables de séquence, en général, sont utilisées pour la fonction de fractionnement de la base de données.

Je dirais que le but est de garder la compatibilité avec Magento 1. Lorsque vous devez migrer des données de m1 vers m2, vous aurez besoin de cette relation.