Friday, May 20, 2005

Posting - Posting - Channel Relationship

Everyone knows that there can be relationship between posting - posting (connected postings) and posting - channel (patent of the posting). But how they are really connected? To understand that, we must have a look at MCMS database schema.

All the objects in MCMS are referred as Nodes in database level. If we take a node of a posting, it will have NodeGuid(Guid of the posting), ParentGuid and FollowGuid. Each node has a type. Type 16 can be a page object or a Posting object. If the IsShortcut value is 1 then the item is a Posting. If it is 0 then it is a Page object. Placeholders are bound to the Page objects. The FollowGuid of the Posting Object points to it's underlying Page object. (Thanks for the clear explanation Stefan!)

  • Posting-Posting

    So all the connected postings will have the same FollowGuid. Because placeholders are bound to the Page objects (IsShortcut=0), connected postings will have reference to the same placeholders.

  • Posting-Channel

    All the posting will have a ParentGuid which are the Guids of the channels. So relationship between posting and channels are maintained via this. So until ParentGuid gets changed, the relationship will be always there.

As a conclusion, Change to any - other than these Guids and IsShortcut, won’t change the relationship. Which means renaming channels, postings wont change relationship.

N.B: This blog is only to make a clear understanding on how postings and channels are related. Handling MCMS database directly or using any undocumented API to handle the database will break the Microsoft support boundary - don't do that.

14 Comments:

Anonymous Stefan Goßner [MSFT] said...

Hi Chester,

not completly true.
Each node has a type. Type 16 can be a page object or a Posting object. If the IsShortcut value is 1 then the item is a Posting. If it is 0 then it is a Page object.
Placeholders are bound to the Page object. The FollowGuid of the Posting Object points to it's underlying Page object.

It would be great if you could set the last sentence in bold red. ;-)

Cheers,
Stefan

5:19 PM  
Blogger Chester said...

Hi Stefan,

I've modified my post. Thanks for making it more clear :)...

As per requested, I've made it in bold-red!

Cheers,
Chester

6:32 PM  
Anonymous Stefan Goßner [MSFT] said...

Hi Chester, you might want to correct the typo: IsSortcut should read IsShortcut.

Cheers,
Stefan

7:46 PM  
Blogger Chester said...

Hi Stefan,

Changed :)

Cheers,
Chester.

7:21 AM  
Anonymous Anonymous said...

try visit your site in Firefox...

2:32 PM  
Blogger Chester said...

I checked it in Firefox and it looks fine... Any problem?

Cheers,
Chester.

2:53 PM  
Anonymous cbretana said...

chester,

Thanks so much! this has been driving me crazy. Could you also add a short comment (if you know) about revisions ?

i.e., are revisions tracked against Pages, or against Postings? Are Placeholders changes also tracked for revisions ? And is all this also done in the node table?

11:25 PM  
Blogger Chester said...

Hi,

Actually revision is also a new page object - bounded to a new set of placeholders. For any posting, there will be only one posting object in database - but can have any number of page objects.

Cheers,
Chester.

1:32 PM  
Anonymous cbretana said...

In your blog, you say

"FollowGuid of the Posting Object points to it's underlying Page object." and ...

"So all the connected postings will have the same FollowGuid"

That implies that Page object is parent of the Posting Object(s),

So your comment above that
"For any posting, there will be only one posting object in database - but can have any number of page objects." can't also be true.. It is saying that Page object is CHILD of Posting object.

12:26 AM  
Anonymous cbretana said...

In playing around with the actual data in the Node table, I have discovered that there are multiple Nodes with type=16, IsShortCut =1, and the same FollowGuid. But there seem to be, potentially up to two nodes with that NodeGuID(= to common FollowGuid), one with ApprovalStatus = 0, and one with ApprovalStatus = 1.

But I do not see any relationship or indication of where nodes might be created to represent Historical revisions...

4:14 AM  
Blogger Chester said...

Sorry, I took more time to reply as I went on a vacation and came back today :).

There was a mistake in my previous statement (I was saying about published one with unapproved one). For revision histories, they have a node which points to its page object with ArchiveSourceGuid.

11:31 AM  
Blogger Tanya Roy said...

This comment has been removed by the author.

3:00 PM  
Blogger Tanya Roy said...


This is really sweet! Just wonderful post written by you. Thank you for your kind post...Impressive work…Independent Bangalore Escorts

3:01 PM  
Anonymous Escorte de Lux said...

Escorte Romania, Ghid de Bucuresti, dame de companie din Romania, fete tinere, studente, fetite blonde, brunete sau roscate, femei rafinate dar in acelasi timp focoase, escorte verificate cu imagini reale si descrieri detaliate disponibile pentru intalnire de scurta sau de lunga durata, escorte in compania carora te vei simti minunat - EscortGuide.ro

9:12 PM  

Post a Comment

<< Home