Forum OpenACS Q&A: New content repository documentation

The current version is available at

http://rubick.com/openacs/content_repository    or
http://rubick.com:8002/openacs/content_repository

Please let me know if you find any errors or inaccuracies. I'll be working on it some in the next few weeks, so it should get filled in more in the future.

Nick also might be working on CR documentation (not sure). If so, maybe we can merge them together.

-Roberto

I think you loose too much with autogenerated tables, the sql for a table is really the best way to document the data model. The same thing happens with the plsql code: it is all autogenerated and never written down anywhere. But that is the requirement for having a dynamic typing system I guess.

I am working on some improvements to the query-writer package which generates the pl for the new/update/delete functions. The improvements include removing all pl, except that necessary to createupdate/delete the parent acs_object. Even this pl is wrapped in a tcl proc acs_object::new/update/delete.

Also there was a tedious process once the datamodel had been created to reenter all this information into the query-writer package. This has been replaced with a wizard which requires you to create the object which is related to the table for the data model, the wizard takes the table and traces the primary key back to the acs_objects table. There are no 16 param limits with this method.

Although the query-writer handles all the dml/pl dynamically, I think I will put in the code for writing out standard tcl procs similar to the acs_object procs. Then using the query-writer for a few minutes would allow the developer to get a set of functions they could use in their application independent of the query-writer.

Anyway my point here is if you are autogenerating code, why not make it tcl code!

As for naming the column revision_id, the views include all the columns of the child tables so if there are names that collide generally the views can't be created.

Great doc, thanks:)

Just fyi, I create my own revisions table and the "x" and "i" views are created for me just fine (I'm on postgres 7.2.4 and OACS 4.6.1).

Also I had some difficulties with integrity constraint violations, etc when I dropped my content types and attributes as well. I have been told they have been fixed in 4.6.3 but just fyi, here is how I delete my content types and attributes:

create function inline_0 ()
returns integer as '
declare
    v_rec       record;
    v_rec_rev   record;
begin

-- unregister the mime types
    PERFORM content_type__unregister_mime_type (
        ''orp_ad'',            -- content_type
	''text/html''                   -- mime_type
    );

   PERFORM content_type__unregister_mime_type (
        ''orp_ad'',            -- content_type
	''text/plain''                  -- mime_type
    );

-- drop the attributes
    for v_rec in select attribute_id,attribute_name
                 from acs_attributes
                 where object_type = ''orp_ad''
    LOOP
        PERFORM cmsf_attributes__unregister_widget (
            v_rec.attribute_id          
        );  
            
        PERFORM cmsf_attributes__drop_attribute (
            ''orp_ad'',
            v_rec.attribute_name            
        );  
    end LOOP;

    return null;

end;' language 'plpgsql';

select inline_0();
drop function inline_0 ();



create function inline_0 ()
returns integer as '
declare
    v_rec       record;
    v_rec_rev   record;
begin


-- Delete personal ads themselves, created in CR.

-- Temporary workaround (fixed in OACS 4.6.3) for:
-- ERROR:  Referential Integrity: attempting to delete latest_revision:
-- from content_item__delete() function.
    UPDATE cr_items set latest_revision = null where content_type = ''orp_ad'';

-- Temporary workaround (fixed in OACS 4.6.3) 
-- We don not have to delete revisions first in 4.6.3.
-- But for now, content_item__delete errors if revisions exist so we do them first.

-- Remove content_type content revisions.
    for v_rec in select item_id
                 from cr_items
                 where content_type = ''orp_ad''
    LOOP

        for v_rec_rev in select revision_id
                     from cr_revisions
                     where item_id = v_rec.item_id
        LOOP
        PERFORM content_revision__delete (
            v_rec_rev.revision_id          
        );  
        end LOOP;
    end LOOP;
        

    return null;

end;' language 'plpgsql';

select inline_0();
drop function inline_0 ();

-- Splitting content_items into separate function
-- seems to have fixed this error:
-- ERROR:  cr_items_rev_type_fk referential integrity violation - key referenced from cr_items not found in acs_object_types
-- whatever;(

create function inline_0 ()
returns integer as '
declare
    v_rec       record;
    v_rec_rev   record;
begin


-- Remove content_type content items.
    for v_rec in select item_id
                 from cr_items
                 where content_type = ''orp_ad''
    LOOP

        RAISE NOTICE ''BEGIN Deleting content item %'',v_rec.item_id;  
        PERFORM content_item__delete (
            v_rec.item_id            
        );  
        RAISE NOTICE ''END Deleting content item %'',v_rec.item_id;  
    end LOOP;

    return null;

end;' language 'plpgsql';

select inline_0();
drop function inline_0 ();

select content_type__create_attribute(
        'pm_project',
        'customer_id',
        'integer',
        'Customer',
        'Customers',
        null,
        null,
        'integer constraint pm_project_customer_fk references organizations'
);

instead of using alter table add column...

Note that by putting the foreign key reference in the column spec (the last argument), I was able to have legitimate foreign key references. I'm not sure if this is supposed to be supported or not, but it works.