Forum OpenACS Development: Re: CR misunderstanding?

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