I just modified dotlrn_community::archive so that it will archive subcommunities. I modeled the code after dotlrn_community::remove_user which also does recurssion inside a transaction and it works fine on dev but I'm still nervous that I could end up with too many transactions inside transactions and have deadlock problems.
Note that dotLRN can have arbitrary levels of subcommunities of subcommunities. I think 4 levels is the most currently used on SloanSpace.
Here is the code.
ad_proc -public archive {
{-community_id:required}
} {
Archives a community. This means that:
1. the community is marked as archived
2. the RemovePortlet callback is called for all users of the
community (both members and GAs) and all the applets.
3. Do this recursively for all subcommunities.
} {
db_transaction {
foreach subcomm_id [get_subcomm_list -community_id $community_id] {
archive -community_id $subcomm_id
}
# do RemoveUserFromCommunity callback, which
# calls the RemovePortlet proc with the right params
foreach user [list_users $community_id] {
set user_id [ns_set get $user user_id]
applets_dispatch \
-community_id $community_id \
-op RemoveUserFromCommunity \
-list_args [list $community_id $user_id]
}
# mark the community as archived
db_dml update_archive_p {}
}
}
Should I take the subcommunity code out of the transaction. In this situation as long as each subcommunity is fully archived it wouldn't be that horrible if the proc failed with only some of the subcommunities archived.
