It is well known that modifying a content database directly by running direct SQL queries results in an unsupported SharePoint state. However, it is possible to develop custom RBS providers. Note that when an item is moved to RBS, RBS provider (e.g. FILESTREAM) creates a blob in the RBS, then sets Content
in AllDocStreams
table to NULL and RbsId
to the generated blob id:
(Image source: http://blogs.technet.com)
Now, RBS API makes it possible to create blobs in RBS and generate blob ids, but there is no mechanism available that would actually update the SharePoint content database correctly after this step. So it seems to me that a developer is forced - after a blob has been created and its id generated - to update the content database directly through SQL, i.e. update Content
to NULL and assign the generated RbsId
. This seems to be the only way of implementing a custom RBS provider, yet it directly contradicts the requirement that content database should only be touched through the SharePoint API.
Am I missing something or is a developer indeed forced to cause unsupported state when developing a fully-functional custom RBS provider? Or would it only be considered unsupported if it prevented a resolution of a potential issue?