CiviCRM Community Forums (archive)

OK, this may not be an API issue only, because I just deleted one event from the UI, and *ALL* of my events were deleted.

However, all the events were created by the API, but they definitely had different event IDs, which should be the only factor passed to the delete function?

I also had some tricks going where multiple records in the events table were sharing the same record in other tables (i.e., location, tell-a-friend). So I wonder if this is some kind of MySQL cascading delete issue? I.e., I deleted the one event, but it caused items in other tables to be deleted, which were shared by other events, which were then, therefore, deleted.

This is difficult to verify on the sandbox, since there are so many events there, and no API access.

Yes, the _event table is empty.

As I said, I cannot replicate on the sandbox/demo. But I can't recreate the exact conditions either, since I can't create events via API on the demo.

OK,

First I create an event with the UI, filling in only the required fields and using defaults otherwise.

Then I run this code twice to make two more event with roughly the same parameters:



$event_id = 1;  //This is the event I created with the UI

  civicrm_initialize();
  require_once('api/v2/Event.php');

  $toFind = array('id' => $event_id);
  $event = civicrm_event_get($toFind);

    $cloned_event = $event;

    unset($cloned_event['id']);
    $cloned_event['start_date'] = '20090513';
    $cloned_event['title'] = $cloned_event['title'] . " COPY";

    $new = civicrm_event_create($cloned_event);

I verify that the new events have unique IDs, but then, if I delete the original (ID=1) or a copy (ID=2 or ID=3), all the events are deleted.

Well, +1 to my previous complaint: http://forum.civicrm.org/index.php/topic,3114.msg13674.html#msg13674

and...

I'd rather err on the side of leaving an unused record in the database than being over aggressive with FK constraints and cascading deletes

i.e., when given the choice between 'keep possibly unneeded data' and 'delete possibly unneeded data', the answer for automated processes (e.g., cascading FKs), is always 'KEEP'.

This should be standard best practice for database schema design, IMO.