Forum OpenACS Development: CR misunderstanding?

I'm trying to use the content-repository for an application I'm building...

I'm a little bit confused by something in the tutorial (http://www.openacs.org/doc/acs-content-repository/tutorial.html):

quote: "One thing you have to be careful of when creating these tables is that there are no columns that have the same names as any of the columns in the cr_items and cr_revisions tables."

however, two tables above (the versioned portion, pm_tasks_revisions),

title varchar(100),
description varchar(4000)

are defined, while these columns (attributes) already exist in the cr_revisions table as follows:

title character varying(1000),
description text

Can anybody explain what is going on here?

Also, somewhat later attributes are added using content_type__create_attribute (start_date, end_date and percent_complete). I understand these columns are added to the revisioned table (in this case pm_tasks_revisions) if they don't already exist. How does anybody decides whether to add those columns using content_type__create_attribute right away, or first using a "alter table add column ..." SQL statement followed by a corresponding content_type__create_attribute call? Do you suggest always exclusively using content_type__create_attribute to add attributes?

much thanks!

kind regards,
koen.

* 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.

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.

This is much easier and makes the interface consistent.

It does invovle some amount of copying of the attributes, but I think the greater simplicity of the code is worth it.

To find the creation date of the item itself you would need to get the creation date of the cr_item that corresponds to the cr_revision row you are working with.