Forum OpenACS Development: Re: Cannot delete groups with segments and rels

Collapse
7: Re: Cannot delete groups with segments and rels (response to 1)
Posted by tammy m on 09/05/03 07:11 PM
Bah!

More bad news for me. When I attempt to delete the group from the Groups Admin page (Nuke this group), I get the same foreign key violation on my group. 

[04/Sep/2003:15:32:53][5032.19476][-conn:openacs-dev::16] Notice: Querying 'select __exec_43_delete_group ();'
NOTICE:  BEGIN Deleting relation composition_rel, id 7420
NOTICE:  identifier "rel_constraint__violation_if_removed" will be truncated to "rel_constraint__violation_if_re"
NOTICE:  END Deleting relation composition_rel(7420)
NOTICE:  BEGIN Deleting segment 7422
NOTICE:  END Deleting segment 7422
NOTICE:  BEGIN Deleting segment 7425
NOTICE:  END Deleting segment 7425
NOTICE:  BEGIN Deleting group 7417
NOTICE:  END Deleting group 7417
[04/Sep/2003:15:32:55][5032.19476][-conn:openacs-dev::16] Error: Ns_PgExec: result status: 7 message: ERROR:  acs_permissions_grantee_id_fk referential integrity violation - key in parties still referenced from acs_permissions

[04/Sep/2003:15:32:55][5032.19476][-conn:openacs-dev::16] Error: dbinit: error(localhost::openacs-dev,ERROR:  acs_permissions_grantee_id_fk referential integrity violation - key in parties still referenced from acs_permissions
): 'select __exec_43_delete_group ()'
[04/Sep/2003:15:32:55][5032.19476][-conn:openacs-dev::16] Notice: Querying 'drop function __exec_43_delete_group ();'
NOTICE:  current transaction is aborted, queries ignored until end of transaction block
[04/Sep/2003:15:32:55][5032.19476][-conn:openacs-dev::16] Notice: dbinit: sql(localhost::openacs-dev): 'drop function __exec_43_delete_group ()'
[04/Sep/2003:15:32:55][5032.19476][-conn:openacs-dev::16] Notice: Querying 'abort transaction;'
[04/Sep/2003:15:32:55][5032.19476][-conn:openacs-dev::16] Notice: Ns_PgExec: Rolling back transaction
[04/Sep/2003:15:32:55][5032.19476][-conn:openacs-dev::16] Notice: dbinit: sql(localhost::openacs-dev): 'abort transaction'
[04/Sep/2003:15:32:55][5032.19476][-conn:openacs-dev::16] Notice: RP (3266.875 ms): error in rp_handler: serving GET /admin/groups/delete-2?group_id=7417&operation=Yes%2C+I+really+want+to+delete+this+group 
        ad_url "/admin/groups/delete-2" maps to file "/www/nsroot/openacs-dev/packages/acs-subsite/www/admin/groups/delete-2.tcl"
errmsg is Transaction aborted: Database operation "0or1row" failed (exception NSDB, "Query was not a statement returning rows.")

Makes sense since ultimately it ends up calling acs_group__delete just like I tried in psql!

So if I do this first 

delete from acs_permissions where grantee_id in (select segment_id from rel_segments where group_id = 7417);
delete from acs_permissions where grantee_id = 7417;

then my call to acs_group__delete(7417); works fine. I think something to this effect should be added to acs_group__delete pl/sql function so that the group delete just works.

Collapse
8: Re: Cannot delete groups with segments and rels (response to 7)
Posted by Randy O'Meara on 09/06/03 05:01 AM
Tammy,

There is a bug (https://openacs.org/bugtracker/openacs/bug?bug_number=234), filed by Tilmann back in February, that discusses the bothersome necessity to delete permissions assigned to an object prior to deleting the object. The problem is much larger and more pervasive than the groups issue you encountered. The ensuing discussion seemed to establish that a cascaded delete from acs_objects to acs_permissions was appropriate.

The patch (https://openacs.org/bugtracker/openacs/patch?patch_number=74) that was submitted to close the bug on that same day doesn't address a cascaded delete that I can see. It does "delete from acs_permissions..." when an object is deleted. Which should guarantee that permissions are deleted before the acs_object.

Somebody that's more familiar with the groups system needs to state whether the suggestion you make (deleting perms from within acs_group__delete) is essentially equivalent to the issue that was resolved by Til's bug/patch, and then apply that change if it's appropriate.

My vote would support such a change if some kernel guru thinks it's the right thing to do.

Don? Til? Jeff?