Sharepoint:当内容类型更新时，基于内容类型的列表会发生什么? [英] Sharepoint: What happens to lists based on content type when content type is updated?

问题描述

我有一个假设性的问题(至少现在是:))

I have kind of hypothetical question (at least for now :))

假设我根据一些自定义内容类型创建列表.我将大约 1000 个项目添加到该列表中(生产中).然后客户来了，他说他需要修改自定义内容类型.

Let's say I create list based on some custom content-type. I add some 1000 items into that list (in production). Then customer comes and he say that he need to modify that custom content type.

如果我修改自定义内容类型，列表会发生什么情况?它会自动更新吗(我怀疑)?那么已经创建的列表项呢?

What happens to list if I modify custom content type? Will it be updated automatically (I doubt) ? And what about already created list items?

你们中有人有这方面的经验吗?

Do any of you have some experience with this?

推荐答案

关于内容类型的几个问题:

So a couple of issues regarding content types:

首先，内容类型有两种形式:站点内容类型和列表内容类型.站点内容类型是驻留在库中的模板".在列表中使用站点内容类型时，该内容类型将实例化为给定列表中的列表内容类型.

First of all, content types comes in two flavours: Site content types and list content types. Site content types are "templates" that reside in a gallery. When a site content type is used in a list, the content type is instantiated as a list content type on the given list.

其次，您的内容类型可以通过多种方式创建和修改，这将决定您的数据以三种模式中的哪一种出现在数据库中.

Secondly, your content types could be created and modified in several ways, which would decide in what of three modes your data is present in the database.

如果您使用 GUI 或通过使用 API 的自定义代码创建了内容类型，则您的网站内容类型和列表内容类型在数据库中都处于仅数据库"状态.这意味着它正在数据库中查找内容类型的定义.

If you have created the content type using the GUI, or through custom code using the API, both your site content types and your list content types are in the "database-only" state in the database. That means that it is looking in the database for the definitions of the content type.

如果您已将内容类型创建为 CAML 中的一项功能，您的站点 内容类型在数据库中是幻影的(或未自定义，因为我们应该在 v3 中调用它).这基本上意味着数据库在 12-hive 中的功能 XML 中查找构成内容类型的网站栏.所以这应该意味着您可以更新该功能，并且您将在更新内容类型中拥有新的网站栏，对吗?

If you have created the content type as a feature in CAML, your site content type is ghosted (or un-customized as we are supposed to call it in v3) in the database. That basicly means that the database looks in the feature XML in the 12-hive for the site columns that makes up the content type. So that should mean that you could update the feature, and you would have new site columns available in the update content type, right?

很遗憾没有:还记得我们也有列表内容类型吗?令人遗憾的是，这些列表内容类型是使用代码实例化的，因此它们处于仅数据库"状态.这意味着您的更改只会在您的网站内容类型中看到，而不会在使用该内容类型的现有列表中看到！

Unfortunately not: remember that we also had list content types? The bummer here is, that these list content types are instantiated using code, so they are in the "database-only" state. It means your changes would only be seen in your site content types, but not in existing lists using that content type!

有多种方法可以解决此问题，解决方案取决于您的需求以及您正在执行的更改类型(删除字段、添加字段、更改字段).

There are several approaches to fixing this issue, the solution depends on what your needs are and what kind of changes you are doing (deleting fields, adding fields, changing fields).

例如，您通常希望保留现有的项目元数据，即使内容类型随时间而变化.如果您通过代码推送列表内容类型中的更改，您将丢失存储在已更改/已删除字段中的数据.对此的解决方案是基于旧的内容类型添加一个全新的内容类型，但具有更改的字段.您将添加新内容类型(通过代码或使用功能 XML)并使用功能接收器或类似功能将新内容类型传播到使用旧内容类型的所有列表，然后将旧内容类型标记为隐藏.这将使保留旧元数据成为可能，但不会使用新元数据以外的其他方式添加新项目.

For example, you would often want to keep your existing item meta data, even though the content type changes over time. If you push through the changes in the list content type through code, you would lose the data stored in the changed/deleted fields. A solution to this would be to add a completely new content type based on the old one but with the changed fields. You would add the new content type (through code or using feature XML) and use a feature receiver or similar to propegate the new content type to all lists that used the old content type, and subsequently mark the old content type as hidden. That would make it possible to keep old meta data but not to add new items using other than the new meta data.

如果您可以直接访问生产环境，并且您的客户治理计划允许，则首选此问题的另一个答案中提到的方法.但是，与 SharePoint 中的其他工件一样，建议以结构化方式部署内容类型.以非结构化方式添加新的内容类型会影响搜索相关性(托管属性)，也可能影响网站的一般分类法(未重用的网站栏等)，因此即使可以将这些更改直接添加到生产网站，我不会推荐它！

The approach mentioned in the other answer to this question would be preferred if you have direct access to the production environment, and if your customers governance plan allows it. As with other artifacts in SharePoint however, it would be recommended to deploy content types in a structured manner. Adding new content types in an unstructured fashion would influence search relevance (managed properties) and could also affect the general taxonomy of the site (site columns not being reused, etc.), so even though it is possible to add these changes directly in a production site, I would not reccomend it!

这使我想到了最后一种方法，这是我推荐的方法，至少对于未来的内容类型:使用功能接收器从一开始就以编程方式创建您的内容类型！这样您就可以始终了解内容类型的真实状态(仅限数据库)，并且您可以采用结构化的方法来管理未来的变化！您可以通过谷歌搜索以编程方式创建内容类型"SharePoint 来找到多种方法来执行此操作

That leads me to the final approach that is the one I would reccomend, at least for future content types: Create your content types programmatically from the beginning using a feature receiver! That way you always know the true state of your content types (database-only) and you can have a structured approach for governing changes in the future! You can find several ways to do this by googling 'create "content types" programmatically SharePoint'

为了完整性:我提到了三种模式.您的内容类型可以采用的最后一种模式是UnGhosted".这意味着您的内容类型是使用功能 XML 创建的，但它已与 12 hive 中的原始 XML 源断开连接.

For completeness: I mentioned three modes. The last mode your content type can be in is "UnGhosted". This means that your content type was created using feature XML, but that it has been disconnected from the original XML source in the 12 hive.

我的朋友 Søren Nielsen 在内容类型方面有一些优点在审核您的内容类型层次结构.上面描述的一些问题可以在 MSDN 文章更新中找到.内容类型.Gary Lapointe 还有一个 STSADM 扩展，可以解决内容类型的一些问题，请参阅传播内容类型更改.

My friend Søren Nielsen has some good points on Content Types in Audit your Content Type Hierarchy. Some of the issues described above can be found briefly mentioned in an MSDN article Updating Content Types. Gary Lapointe also has an STSADM extension that addresses some of the problems with Content Types, see Propagate Content Type Changes.

抱歉我的吐槽，但主题很复杂，需要彻底解释以避免任何误解.

Sorry for the rant, but the subject is complex and demands a thorough explanation to avoid any misconceptions.

这篇关于Sharepoint:当内容类型更新时，基于内容类型的列表会发生什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！