Hi Luke,
Actually, the problem I am referring to concerns the deletion of an ETP instance, not the ETP package. Setting the package_id to null in the drop script still won't allow me to delete the ETP instance, because this action will be performed only upon removal of the entire ETP package. I don't think there is a way around this unless we specify in cr_folders:
create table cr_folders
...
package_id integer references apm_packages on delete cascade;
where "on delete cascade" will signal ETP when a package instance is to be deleted. Then, the ETP instance contents can be archived in content repository by defining a delete trigger that sets package_id to null:
create function etp_delete_trig() returns opaque as '
update cr_folders
set package_id = null
where package_id = old.package_id;
return old.package_id;
end;' language 'plpgsql';
create trigger etp_delete_trig before delete
on cr_folders for each row
execute procedure etp_delete_trig();
Gosh, now that I wrote it down, I realize this is
really ugly because:
- we need to change the cr_folders table definition to add "on delete cascade", which is part of the acs-content-repository datamodel and not ETP
- we just created a trigger on an acs-content-repository table, which is not part of ETP (there goes package abstraction...)
So why not mimic the design of file-storage, where a separate table is created that maps package_id in APM and the folder_id in cr_folders? This approach maintains package abstraction, in that it does not alter in any way the datamodel of acs-content-repository. If we do the same for ETP, there will be a table in the ETP create script, like
create table etp_to_cr_map (
package_id integer references apm_packages on delete cascade,
folder_id integer references cr_folders
);
which gets an entry whenever a package instance of ETP is created (the package_id in cr_folders will not get used). Since we want the contents of the ETP instance to remain in content repository, "on delete cascade" will simply break the mapping between the package instance and the contents in CR when the ETP instance is deleted (we may have to set folder_id to null first through a trigger to avoid RI violations, but still the trigger will be on an ETP mapping table, not an acs-content-repository table).
A separate issue though is if we really want ETP content to be orphaned in acs-content-repository when the ETP instance is deleted. I think the better solution is to put content under the "Trash" subdirectory when an ETP instance is deleted (again, using a trigger), but clean up everything under "Trash" when the entire ETP package is deleted (through the drop script).
