Contentstatus columns


Does anyone know what any of the following columns are for in the CONTENTSTATUS table in Rhythmyx 6.5.2…?





Of course we know.

The edit and tip revisions are used when checking out the document. Read my API recommendations document: I explain what the various revisions are used for.

The HIB_VER column is the Hibernate Version value used for concurrency control inside Hibernate. Don’t mess with it.

The Content State Id is the workflow state id for that item.


Sorry Dave, I didn’t mean to imply that you didn’t know. Thank you for the information. I had forgotten about the API Recommendations document.


Some experimentation reveals the following alternative explanations of the revision columns in the CONTENTSTATUS table. Please correct me if anything below is wrong:
[li]CURRENTREVISION starts at 1 and, after the item has been to Public* for the first time, is incremented by one every time the item is checked-in. (This includes being returned to public, if the item was checked-out while in Quick Edit**, but not if it wasn’t checked-out while in that state.)[/li][li]TIPREVISION starts at 1 and, after the item has been to Public for the first time, is incremented by one every time the item is checked-out. This includes editing and quick editing, as those menu entries automatically check the item out before opening the item in the Content Editor.[/li][li]EDITREVISION equals TIPREVISION while the item is checked-out and is set to -1 while the item is checked-in.[/li][li]REVISIONLOCK starts as null. It is set to N when it is first checked in. It is then set to Y the first time the item is sent to public and then never modified again.[/li][li]PUBLIC_REVISION starts as null. It is set to the same as CURRENTREVISION whenever the item is transitioned to Public.[/li][/ul]
Revisions are not created every time you edit an item. Nor are they created until the item has been to public at least once. And, if you check an item out and then back in again without editing it while in Quick Edit, you will create two identical revisions.

  • or whatever you call the publishable=publish state in your workflow(s)
    ** or whatever you call the publishable=ignore state in your workflow(s)


You’ve pretty much described what happens in Rhythmyx 6.5.x.

The only caveat that I would like to add is that you should not rely on the Tip Revision: use the Edit Revision when the item is checked out and the Current or Public revision (depending on the circumstances) when the item is not checked out.

It is possible to set the REVISIONLOCK column on creation (so that items are “born” in the Locked state instead of waiting until they go public the first time).

The Public Revision should also be reset (to null or -1) when the item enters an Archive or Unpublish state.


Thanks for the clarification. Also worth noting is that check-out is the point at which new rows are added all the tables containing the local and shared fields, with the REVISION of each new row created set to be the same as EDITREVISION in CONTENTSTATUS.

And this is also the point at which a new row is added to the PSX_OBJECTRELATIONSHIP table if the item being checked out is the “owner” in a relationship with another item (e.g. one or more other items have been added to its slots.) A new row is created even if you check the item back in again without modifying its relationships in any way. The OWNER_REVISION field is again set to the EDITREVISION from CONTENTSTATUS. But checking-out an item which is the “dependent” in a relationship does not appear to create new rows or set the DEPENDENT_REVISION field. In fact, the DEPENDENT_REVISION nevers seems to be set to anything but -1 (although none of our workflows have a publishable=unpublish state yet, so maybe that’s what that column is for.)

I’m still curious about the HIB_VER field in CONTENTSTATUS. I know we shouldn’t mess with it, but it would be good to know what triggers it to be set and modified.