Forum OpenACS Development: CR misunderstanding?

Collapse
Posted by Koen Breugelmans on
Hello,

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.

Collapse
2: Re: CR misunderstanding? (response to 1)
Posted by Malte Sussdorff on
That tutorial is outdated and needs cleanup. I will most likely do this within the next week, you should look at https://openacs.org/test-doc for an up to date documentation.

You do not need these two table columns as they are already defined in cr_revisions. Also all calls you have seen there with regards to pl/sql should not be done this way but you should use the TCL functions like "content::item::new or content::type::new"

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.

Collapse
4: Re: CR misunderstanding? (response to 2)
Posted by Don Baccus on
It's not outdated in regard to the question.

The duplicate columns should not be there. They should be removed from the package.

The reason for the restriction is that the input and output views will return two columns...

select ... content_revision.title ... yourtable.title ...

the second one will "win".

and also this would break anything which, say, lists cr content for a package using the base type's "title" attribute.

Packages shouldn't break other packages or utilities that use the object datamodel correctly ...

Collapse
6: Re: CR misunderstanding? (response to 1)
Posted by Dave Bauer on
Is there any compelling reason not to just copy the un-versioned attributes for every revision?

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.

Collapse
9: Re: CR misunderstanding? (response to 6)
Posted by Koen Breugelmans on
Hello,

After rethinking my data-model, the pieces start to fit for me. I was trying too much to reuse my original data-model, which consisted of unversioned data in tables, linked together with foreign keys. Using the CR correct, and restructuring my data in a hierarchy using content-item's parent_ids (and relations to do more advanced linking), I'm now able to do the same without giving up on the constraints I need...

Lesson learned. While trying to migrate my old system to use the content-repository, I focused too much on my old data-model while I needed a slighty different mindset for this.

thanks everybody

greetz,
koen.

Collapse
7: Re: CR misunderstanding? (response to 1)
Posted by Dave Bauer on
You are correct that the cr_revisionsx view provides the creation date, last modified date,etc of the revision row you are working with.

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.