Forum OpenACS Development: CR pkg: cr_items.live_revision X cr.items.publish_status
Debugging my custom code, which is integrated with acs-content-repository, I’ve noticed a few cases that cr_items.live_revision has a revision_id while cr_items.publish_status is whether empty, production or any other status but live.
Then I started to wonder what caused that mismatching, if I’ve reused CR’s API ad_procs into every chunk I’ve written to create, edit, publish, unpublish items and revisions (content objects). The custom code I’ve written is not even touching in the core’s data model.
Shouldn’t they be always matching ? (meaning if there’s a revision_id into cr.live_revision then there must be “live” into cr.publish_status).
Btw, I’m amazed with the levels of abstractions implemented by Don within acs-subsite.package-procs
It’s just beautiful how Don has abstracted such code to generate plsql functions dynamically.
gets “pieces” together
(i.e. $pieces , $__object_name and$__package_name)
in order to mount “in this case”
The term "live" is used in the content-repository on revisions and items for two different purposes:
to indicate, which revision should be used by default for an item (similar to e.g. a "master" revision on github)
to indicate the
publish_statusof an item, which state is the item in (the
publish_statusis designed to go from
These are different concepts: a revision might be the newest one (a live revision), but the whole item might be in a state not "ready for the public" (indicated by a value of the publish_status of e.g.
The OpenACS content repository does not prescribe, what values of the
publish_status have to be used by an application. The most common packages distinguish just between two different values for publishstatus (see below for the usage of the `publishstatus` on openacs.org.
openacs.org=# select count(*),publish_status from cr_items group by 2; count | publish_status -------+---------------- 26450 | ready 4005 | 292 | production (3 rows)
Indeed! Strictly by the book!
For the record, references are:
Still, it doesn't change the fact that if the cr_items.live_revision is assigned to a revision_id, then cr_items.publish_status must be equals to 'live'. (i.e. that's my assumption)
Otherwise, cr_items.live_revision would be null and cr_items.publish_status equals to any other status, but 'live'.
For instance let's say, portrait-user has revision_id equals to 1706, but its status is ready. That's inconsistent.
Whether cr.publish_status should be 'live' or cr.live_revision should be null.
1704 | 1700 | portrait-of-user-1700 | | 1706 | 1706 | ready | image | file | CR_FILES
Again, based on the assumption that if live_revision is not null then this item must be live. If it's not live then live_revision must be null
<joke> arrggg! Almost a deadlock kind of thing!!! rsrsrs :) </joke>
Please, correct me if my logic is wrong.