Forum OpenACS Development: Re: CR pkg: cr_items.live_revision X cr.items.publish_status
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.