Forum OpenACS Development: package-drop.sql - policy for integration with other packages
disabling the secondary package items items
This means deactivation with without removing the items, just disable them. In ecommerce this means 'discontinue' them - in other packages it may mean modifying delete_p to true.delete the secondary package items from the DB
Advantage - you only delete the one package and won't affect anything else.
Disadvantage - you can be left with a lot of discontinued and deleted_p items in the database that seem that show up randomly. In time, or at if somebody else takes over a job, these things would seem cluttering.
Advantage -If you wanted to get rid of a package you truly did get rid of it. If the drop scripts are primarily a function of development this is probably preferable.leave secondary package items alone
Disadvantage - It can be tedious to set up, i.e. in ecommerce this would mean not only deleting the products but also all all associated objects (i.e. orders for those products). Somebody doing this on a production site may be deleting more than they think they are.
Advantage - you will not 'accidentally' delete something you care aboutA combination of the above
Disadvantage - it could be very cluttered and cause links to be broken
Advantage - you can deal with this on a case by case basis depending on the packages you use as secondary packages and how they are integrated with your package.Please let me know if you can think of other issues here. My vote is for a combo - disabling the secondary items if it is possible to disable them, if and only if some tertiary items maybe associated with those secondary item, AND it is possible to disable them (which in ecommerce it is). If no tertiary items could be associated, or disabling is impossible then delete them from the DB all the secondary, as well as tertiary items.
Disadvantage - no consistency throughout openacs unless guidelines are established.