Forum OpenACS Development: Re: CR misunderstanding?

Collapse
3: Re: CR misunderstanding? (response to 2)
Posted by Koen Breugelmans on
excellent, I'm now able to

* create a new content-type my_items_revisions with content::type::new (supertype cr_revisions)
* add attributes to content-type my_items_revisions with content::type::attributes::new
* create new content items (content::item::new with content-type my_items_revisions) and revisions to an existing content item (content::revision::new, content-type fetched from the item)

The above gives me all revisioned attributes, which is great.

But can I use the revisioned table + unrevisioned table setup from that tutorial? I have some attributes that don't really need to be revisioned, but more importantly, need to be unique all together for a particular content-item.

Does it go like this?
* create a new content-type my_items of supertype cr_items
* add unrevisioned attributes to content-type my_items
* each time a new content-item needs to be created, we content::item::new (content-type my_items) and content::revision::new (content-type my_items_revisions)

Or should I rather work with just a revisioned table (supertype cr_revisions) and put a unique constraint over the attribute columns I want item-unique + item_id to the extended revision table? I remember I've read something about constraints on CR revision-tables, but can't remember where.

gracias,
koen.

Collapse
5: Re: CR misunderstanding? (response to 3)
Posted by Koen Breugelmans on
my findings after some experimentation:

content::item::new does only allow new items of content_type cr_revisions (or a subtype) to be created. if I understand correctly, it doesn't provide unrevisioned attributes to items on its own.

the easiest way I see at the moment to have unrevisioned attributes to an item is to manually create an unrevisioned table (with the unrevisioned attributes) and to insert a row there when creating the new item with content::item::new (and remove the row when deleting the item).

does anybody have to add something to this?

next I wonder about the x-view that is created when I create a new content-type (subtype of cr_revisions). it contains a row for every revision and some columns (amongst others):

creation_user
creation_date
creation_ip
last_modified
modifying_user
modifying_ip
publish_date

I kind of "expected" creation_* to reflect the initial creation of the item or the first revision of that item, and last_modified & modifying_* to reflect each revision itself.

however,
* creation_date and last_modified always seem to be the same and reflect the revision (while I thought creation_date would reflect the item),
* so are creation_ip and modifying_ip,
* creation_user reflects the revision not the item,
* modifying_user is always empty?
* publish_date -- don't know what this is

in the definition of the x-view, all above columns come from the row in the acs_objects table that provides the object for a particular revision, so this probably explains why.

So, am I correct when I say that creation_* in the x-view reflects the creation of a new revision, and last_modified & modifying_* for editing a particular revision afterwards? This seems strange as the whole point of revisions in the content-repository is not to edit them, but to create a new one when something changes.

greetz,
koen.

Collapse
8: Re: CR misunderstanding? (response to 5)
Posted by Tom Jackson on
Most(all) of these attributes are from acs_objects, and not all acs_objects are cr_items/revisions.

If I were to use these fields, I would use them just as they are for every other acs_object (when they are used). And that means that if you modify the object, change the modification info. Not all modifications are revisions, in fact, I would think that in general, attribute changes are not revisions, and shouldn't be tracked as revisions. Otherwise you run into a whole series of logical problems. Minor typos or fixing obvious non-factual mistakes, are not revisions either, but they could be handled (and probably are more easily handled) as a revision. If not, do an in-place edit and change the modification info.

But each item/revision is a distinct acs_object, not to be confused with the versioned object in the cr.