SharePoint 2010: Anatomy of Managed Metadata Fields

From an end-user perspective it looks like there is only one field type that creates only a single taxonomy field in sharepoint; but this is not the whole story behind managed metadata fields. If a managed metadata field will be created SharePoint creates two fields instead. For this post I create a field called “TaxTest” which creates the field itself and a field “TaxTest_0”. I will use this field name for reference.

Let’s take a closer look on both fields that was created

• “TaxTest” Field is type of “TaxonomyFieldType”
• “TaxTest_0” field is type of “Multiple lines of text”

The TaxTest field is basically a lookup field. The target to look up is a hidden list in every site collection called TaxonomyHiddenList. This list only exists once per site collection and stores ever Managed Metadata term that ever was used in your site collection. The list cannot be found in SharePoint because it is a hidden list but can be located using the following URL pattern:
 **    http://<yourserver>/<sitecollection root>/Lists/TaxonomyHiddenList** or root site collection.
Field values stored in this field has also the same pattern as lookup fields and look like this: “1;#Test Term”

The “TaxTest_0” field will only store key/value pairs which looks like this:

TestTerm|15017394-438b-4c1d-b710-454c7055cc7
<Term value from Taxonomy Store>|<Term Guid from Taxonomy Store>

That’s all for now from these fields I will continue later on with this.

Taxonomy Hidden List

The taxonomy hidden list has two base functionalities. The main reason is the list and view performance in special and SharePoint performance in general. It is much easier to lookup field values from this list than perform a query against the term store every time the data will be used. So if a new term is added to any list in your SharePoint site collection the value will be added to this list.

The second reasons for this list is that changes to in the Taxonomy Store only have to be done to a single list instead of propagate the values to every list and every list item. I think it is a really smart solution to handle massive updates from the taxonomy store.

If a user change, merge or deletes a term in the term store management a timer job will handle the update to the Taxonomy Hidden list. The timer job is called “Enterprise Metadata site data update”. One timer job exists for ever web application. If a changed term will be added to a list item the update goes directly to the hidden taxonomy list in case the timer job was not executed already.

http://www.n8d.at/blog/wp-content/uploads/2011/05/mmdtimerjob-300x130.png
Managed Metadata Timer Job

The field on the list are quite self-explaining. You have some Guid that identifies the values in the term store. The different language values of the term will be stored there too. So again I think it’s quite smart from a performance perspective. The catch all field will be used for queries I think but I’m not sure about this. Documentation also lacks a little bit about that.

http://www.n8d.at/blog/wp-content/uploads/2011/05/taxonomyhiddenlist-300x169.png
TaxonomyHiddenList Item View

As always this list should never be changed or update by any user or code. This list is system managed and therefore should only be changed by the system. You can take a look, browse or query but never change anything.

Field usage in SharePoint

The last question to answer is how SharePoint renders the Taxonomy Fields and where which field will be used.

The TaxonomyFieldType (“TestTax”) field will be used whenever it is necessary to display the values from the TaxonomyHiddenList. This field type behaves like a normal lookup and will be rendered as a lookup.
Usage: Display form of list items and views.

TestTax_0 field which is a “multiline of text” field type will be used to find and resolve the terms from the Taxonomy Store.
Usage: New and edit form of list item.