Forum OpenACS Development: CR pkg: cr_items.live_revision X cr.items.publish_status

Collapse
1: CR pkg: cr_items.live_revision X cr.items.publish_status
Posted by Iuri Sampaio on 03/03/18 09:17 PM
Hi there,

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
Genius!
It’s just beautiful how Don has abstracted such code to generate plsql functions dynamically.

How package_exec_plsql
gets “pieces” together
(i.e. $pieces , $__object_name and$__package_name)

in order to mount “in this case”
content_revision__is_live

/api-doc/proc-view?proc=package_exec_plsql&source_p=1

/api-doc/plsql-subprogram-one?name=content_revision__is_live&type=FUNCTION

Best wishes,

Collapse
2: Re: CR pkg: cr_items.live_revision X cr.items.publish_status (response to 1)
Posted by Gustaf Neumann on 03/13/18 08:47 AM

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_status of an item, which state is the item in (the publish_status is designed to go from production*, overreadyandlivetoexpired`).

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. production).

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.

-g

openacs.org=# select count(*),publish_status from cr_items group by 2;
 count | publish_status 
-------+----------------
 26450 | ready
  4005 | 
   292 | production
(3 rows)
Collapse
3: Re: CR pkg: cr_items.live_revision X cr.items.publish_status (response to 2)
Posted by Iuri Sampaio on 03/14/18 12:43 AM
Hi Gustaf,

Indeed! Strictly by the book!

For the record, references are:
1. https://openacs.org/doc/acs-content-repository/
2. https://openacs.org/doc/acs-content-repository/guide/revisions

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.

Best wishes,

Collapse
4: Re: CR pkg: cr_items.live_revision X cr.items.publish_status (response to 3)
Posted by Gustaf Neumann on 03/14/18 09:16 AM
Your assumption is wrong. There is no coupling between the publish_status of the item and the actual revision.