Когда SPFile.Properties! = В SPFile.Item.Properties в SharePoint?

Question

У одного из наших клиентов есть проблема, которую мы не можем воспроизвести. Мы программно копируем свойства документа в файл назначения с помощью SPFile.Properties. Однако по какой-либо причине свойства файла не соответствуют метаданным, указанным в списке, в котором хранится файл.

Теперь, возможно, мы сможем решить эту проблему, скопировав SPFile.Item.Properties (еще не проверенный), но я просто интересно, при каких обстоятельствах SPFile.Properties не соответствует SPFile.Item.Properties.

Обновление: Мы только что получили сообщение от нашего клиента. Использование SPFile.Item.Properties всегда возвращает обновленную информацию. Однако мы все же хотели бы понять первоначальный вопрос.

Answer 1

Существует небольшая разница между полями SPFile.Properties и SPFile.Item, и первая из них намного медленнее.

Возможно, вы, скорее всего, видели «свойства» документа Microsoft Office (этот - http://dradisframework.org/images/tutorial/custom_document_properties.png). Это свойства, которые читаются при доступе к SPFile.Properties. Чтение их происходит медленно, поскольку существует некоторая инфраструктура кода, которая анализирует двоичный файл DOC и находит свойства. (занимает до 30 или что-то миллисекунды для каждого доступа к ресурсам). Подробнее см. здесь: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfile.properties.aspx

В SharePoint каждый элемент является SPListItem и его значениями полей (и здесь я не использую слово «свойства») хранятся в базе данных контента Sharepoint. Итак, когда вы обращаетесь к SPFile.Item.Properties, вы действительно смотрите на SPListItem, к которому прикреплен файл, и посмотрите его свойства из базы данных контента SharePoint.

Что происходит за сценой, когда вы загружаете файл, имеющий некоторые свойства «Office», заключается в том, что SharePoint копирует их в поля с одинаковым именем в SPListItem. (Некоторые сведения об этом здесь: http://weblogs.asp.net/bsimser/archive/2004/11/22/267846.aspx)

Вот почему эти свойства обычно имеют одинаковое значение, НО это происходит только в том случае, если SharePoint знает, как читать метаданные из вашего файла и записывать их обратно. Итак, если вы положили файл .txt в свой магазин SharePoint, вы не получите никаких SPFile.Properties.

Answer 2

Попытка найти «официальное документированное» что-либо для sharepoint в значительной степени отменяется. :-D. Онлайн-документы сосут, вы лучше используете записи в блогах и т. Д.

P.S. Я согласен с Алексом здесь. Хотя SPFile никогда не существует в списке без сопровождающего SPListItem, соединение между 2 может быть повреждено (т. Е. Возможность редактировать элемент списка, но файл не открывается). Это для меня указывает, что информация о 2 хранится в разных местах в содержимом db. Раньше это случалось раньше.

Answer 3

Пользователь всегда будет видеть свойства ListItem, а не свойства SPFile в библиотеке документов. Поэтому использование свойств ListItem в копии - путь.

Answer 4

Я полагаю, что эта проблема связана с функцией продвижения/понижения свойств Sharepoint, которая позволяет встраивать свойства документа в файл физического MSOffice и перемещаться вместе с ним клиенту и т. Д. Однако это поддерживается только в настоящее время для типов файлов Office (насколько мне известно).

Jonathan