Forum OpenACS Development: Calendar pkg: call_item and acs_activity
Are they supposed to stay in the datamodel?
Since I've found no references in /api-doc to remove acs_activities, I've written the code to manually remove them, but I'm not sure if it's complete. Perhaps, I could have missed anything.
::xo::db::sql::acs_activity delete -activity_id XXXX
the technical reason why activities don't get removed automatically at the removal of a cal_item is this: cal_items.cal_item_id references acs_events.event_id, but no ON DELETE behavior is defined. On the other hand, acs_events.event_id references acs_activities.activity_id and there we have ON DELETE SET NULL defined. Therefore, is not clear to me whether automatic deletion of related activity and event tuples is fine in general for all packages that reuse acs-events.
I will try to have a deeper look, in the meantime whoever might have better insight could give some comments.
actually, if one looks at calendar::item::delete -cal_item_id https://openacs.org/api-doc/proc-view?proc=calendar::item::delete&source_p=1, this should call ca_item__delete stored procedure https://openacs.org/api-doc/plsql-subprogram-one?name=cal_item__delete&type=FUNCTION, which should in fact remove the acs_event.
Are you making use of this API? Or you're deleting via some custom code?
I've used cal_item__delete and I haven't touched into the core's ad_procs.
Pkg versions are:
provides url="calendar" version="2.6.1d3"/
provides url="acs-events" version="0.6.1.1"
provides url="acs-kernel" version="5.9.1"/
I've noticed the dependencies (relationships) among calendar, acs-events and so, while I was debugging the "code workflow".
Thanks for the lesson! I understand why acs-events supports calendar pkg. It makes total sense.
I've looked into the problem. Iuri is right, there is a problem of acs_activities not being reclaimed. However, the situation is tricky and depends on some details, especially with recurrences.
calendar entries with recurrences: when a calender entry is created, which contains recurrences, technically the calendar entry generates multiple
acs_events) all pointing to a single
activity_id. A user has the option to delete each of these
cal_itemsseparately, only when the last of these
cal_itemsis deleted, the
recurrence_id) could be deleted.
calendar entries without recurrences: when the
cal_itemis deleted, the
activity_idcould be deleted as well.
The problem is that neither the
activity_id nor the the
recurrence_id are deleted, even when they could. For more details, see the new test case i have added to the code repository just now.
As a consequence of this, orphan
acs_activities (and potentially recurrences) might be kept in the system. When only calendar created
acs_activities and recurrences, the following two queries should return 0.
select count(*) from acs_activities where activity_id in (select activity_id from acs_activities except select activity_id from acs_events); select count(*) from recurrences where recurrence_id in (select recurrence_id from recurrences except select recurrence_id from acs_events);
i'll prepare a patch and commit it in the near future.