Orchard has a really neat concept of identity that’s mainly used when importing contents into the CMS. One of the difficulties with importing contents is that you need to make sure that you can import not just new items, but also updates to existing items. For this to work consistently, we need to be able to identify a content item reliably.
We do have an obvious identifier for content items, the content item id, but we can’t use that: it’s not strictly part of the content data, but is rather an internal database identifier that is there to establish table joins. If the same content item exists on two different Orchard instances, the id will likely be different. What we need instead is an identifier that is derived predictably from actual content data.
If the content item has the Autoroute part, for example, its alias is a perfect identifier. On a product content type, that could be the SKU. Where nothing is available, we can create a GUID at the same time as the item (the Identity part does exactly that).
That also means that some items have potentially more than one identifier. Import/Export recipe files store those in one single id attribute, as a slash-separated list of key-value pairs (the whole approach is inspired by X.500):
If we wanted to make real world analogies, each key-value pair would be a form of id (like your driver’s license, your id card, or your library card), and the id attribute is your wallet. Any form of id is sufficient to identify you. You don’t need to show every single form of id in your wallet. Even if you lost or forgot your driver’s license and your library card, your id card would still be enough.
Or at least that should be the case. Until now, however, the implementation in Orchard was completely wrong, and you actually needed the whole wallet in order to import properly. I pushed a fix in 1.9 that finally implements the correct behavior. With this change, you can now, for example, generate an import file from your product catalog, using the SKU as the identifier, and import that file repeatedly without creating new items each time. Even though other identifiers will be created on publication by other parts such as Autoroute, those won’t affect the recognition on subsequent imports because the identity matching can still be done on the SKU identity token alone.
And that is pretty neat…