Forum OpenACS Development: Response to Edit This Page 2.0 project

Collapse
Posted by Jowell Sabino on
Since acs-content-repository allows you to store content in the database (as lob or text) or in the filesystem, how about a parameter that lets you specify how content is stored? For performance reasons, some sites may want to store ETP content on the filesystem.

3.4 Likewise, when a subtopic is deleted, ETP must delete the package and site node for you.

Will this also allow deletion of the package instance from the site map (i.e., not from the ETP admin interface)? ( See this). When a package is deleted from the site map, it calls apm_package__delete. There should probably be "on delete cascade" constraint imposed on the package_id attribute in cr_folders for this to happen.

Speaking of this new attribute, package_id, added to cr_folders, are we now assuming that whenever a package is built on top of acs-content-repository, a new package instance is created for every folder in cr_folders? Sorry, I really don't understand why package_id is now in cr_folders. Why can't a package (say ETP) create, if needed, a mapping table that maps cr_folders and apm_packages, with two attributes: package_id and folder_id? It accomplishes the same thing, but it still maintains the cleaner separation between acs-content-repository and any package that builds on top of it. File-storage does not assume that every folder is a package instance, for example.

5.2 An alternative to the triggers defined in the content repository’s content-search.tcl is necessary. ETP will provide triggers on the cr_items table that only submit changes to the search indexer when an item is published.

Aren't you changing the datamodel of acs-content-repository this way (no more package abstraction)? It seems to me that this trigger will benefit more than ETP, so why not make this trigger part of acs-content-repository? ETP (or any package for that matter) should not be creating triggers on CR tables.