3

When updating civicrm/civicrm-core (5.28.3 => 5.29.0), the process get frozen while

[Executed: Upgrade DB to 5.29.alpha1: Fill civicrm_relationship_cache (1 => 5000)]

After reinstallation of a backup and removal of all caches, still the update gives a same frozen installation.

===========

Here's what I found in the Civi logs:

465 Sep 07 20:44:40 [info] $CRM_Queue_Page_AJAX_runNext_error = PEAR_Exception: "DB Error: constraint violation"

421 Sep 07 20:44:40 [debug] $backTrace = #0 /PATH/vendor/civicrm/civicrm-core/CRM/Core/Error.php(937): CRM_Core_Error::backtrace("backTrace", TRUE)

385 Sep 07 20:44:40 [error] $Fatal Error Details = Array

383 Sep 07 20:44:39 [info] Running task: Upgrade DB to 5.29.alpha1: Fill civicrm_relationship_cache (5001 => 10000)

381 Sep 07 20:44:37 [info] Running task: Upgrade DB to 5.29.alpha1: Fill civicrm_relationship_cache (1 => 5000)

379 Sep 07 20:44:37 [info] Running task: Install eventcart extension

377 Sep 07 20:44:36 [info] Running task: Upgrade DB to 5.29.alpha1: SQL

375 Sep 07 20:44:36 [info] Running task: Upgrade DB to 5.29.alpha1

373 Sep 07 20:44:35 [info] Running task: Begin Upgrade to 5.29.alpha1

371 Sep 07 20:44:35 [info] Running task: Checking extensions

369 Sep 07 20:44:34 [info] Running task: Cleanup old files

=========

In Drupal's logs :

Message Warning: Declaration of CRM_Volunteer_BAO_Project::copyValues(&$params, $serializeArrays = false) should be compatible with CRM_Core_DAO::copyValues($params) in require_once() (line 36 of /PATH/web/sites/default/files/civicrm/ext/org.civicrm.volunteer/CRM/Volunteer/BAO/Project.php)

  • Is there anything in ConfigAndLog or the web server log? – Demerit Sep 7 at 12:52
  • It completes 1-5000 of "Fill civicrm_relationship_cache" and then fails in 5001-10000 so presumably there is some relationship with unexpected values. That is an abbreviated version of the log - can you add the full details of the error? It should give more information about the constraint violation. – Aidan Sep 8 at 9:31
7

We got this on one of the db upgrades. For us, it was due to few entries in civicrm_relationship table which were attached to permanently deleted contact ids. You can follow the below steps to complete the upgrade process.

  • Take a separate back up for civicrm_relationship table.

  • Check invalid entries using -

    select id 
    from civicrm_relationship 
    where contact_id_a not in (select id from civicrm_contact) OR contact_id_b  not in (select id from civicrm_contact)
    
  • Delete these rows

    delete from civicrm_relationship 
    where contact_id_a not in (select id from civicrm_contact) OR contact_id_b  not in (select id from civicrm_contact)
    

Complete the upgrade process. Hope that works.

| improve this answer | |
  • 1
    I'm sharing the problem with OP and this solution helped me partially. I have a clean backup from a month ago. When I deleted orphan relations as suggested here on that backup and upgrade, works perfect. The problem is that, on the live-production copy it doesn't change the situation... But that's another problem for sure. Thank you very much for your help. – loker Sep 24 at 11:50
  • I applied the @jitendra, and found 49 relationships that I delayed. Then the update went smooth. Thank to all ;-) – Ichi Oct 4 at 10:43
0

The logs add been moved to the first post

| improve this answer | |
  • Since this is further information about the problem and not an answer, please edit your original question and copy this into it. – Aidan Sep 7 at 20:15
  • Agree with Aidan it should be an edit to the original question. The "constraint violation" suggests that it's trying to insert a row where it's violating one of the table constraints, like the contact_id doesn't exist as a contact, but I'm not sure how that would happen. You might need to debug CRM/Upgrade/Incremental/php/FiveTwentyNine.php in populateRelationshipCache(). – Demerit Sep 7 at 20:37
  • @Aidan and Demerit Yes, understood ;-) I added the informations to the original post. In the database, I cannot locate the civicrm_relationship_cache – Ichi Sep 8 at 6:14
  • When such a thing happens as I doubt to be able to debug, is it easier to create an empty CiviCRM database 5.29.0 and to import via SQL the content of the earlier 5.28.3 ? – Ichi Sep 8 at 6:19
0

@Ichi has a point as I am troubleshooting some issues and have just done exactly what was suggested. You may need to restore your WP DB and CiviCRM DB fro your existing DBs after fresh installs of WP and CiviCRM. A few changes to the WP and possibly CiviCRM table name prefixes in wp_config.php and then civicrm.settings.php and you should be right to go. Good luck!

| improve this answer | |
0

I had a similar problem, but only on a Drupal 8 site I upgraded; the others went fine.

I ran the following SQL to create the new table civicrm_relationship_cache, then ran cv upgrade:db --retry so that CiviCRM would pick up from where it had failed.

CREATE TABLE `civicrm_relationship_cache` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Relationship Cache ID',
  `relationship_id` int(10) unsigned NOT NULL COMMENT 'id of the relationship (FK to civicrm_relationship.id)',
  `relationship_type_id` int(10) unsigned NOT NULL COMMENT 'id of the relationship type',
  `orientation` char(3) COLLATE utf8_unicode_ci NOT NULL COMMENT 'The cache record is a permutation of the original relationship record. The orientation indicates whether it is forward (a_b) or reverse (b_a) relationship.',
  `near_contact_id` int(10) unsigned NOT NULL COMMENT 'id of the first contact',
  `near_relation` varchar(64) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'name for relationship of near_contact to far_contact.',
  `far_contact_id` int(10) unsigned NOT NULL COMMENT 'id of the second contact',
  `far_relation` varchar(64) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'name for relationship of far_contact to near_contact.',
  `is_active` tinyint(4) DEFAULT 1 COMMENT 'is the relationship active ?',
  `start_date` date DEFAULT NULL COMMENT 'date when the relationship started',
  `end_date` date DEFAULT NULL COMMENT 'date when the relationship ended',
  PRIMARY KEY (`id`),
  UNIQUE KEY `UI_relationship` (`relationship_id`,`orientation`),
  KEY `index_nearid_nearrelation` (`near_contact_id`,`near_relation`),
  KEY `index_nearid_farrelation` (`near_contact_id`,`far_relation`),
  KEY `index_near_relation` (`near_relation`),
  KEY `FK_civicrm_relationship_cache_relationship_type_id` (`relationship_type_id`),
  KEY `FK_civicrm_relationship_cache_far_contact_id` (`far_contact_id`),
  CONSTRAINT `FK_civicrm_relationship_cache_far_contact_id` FOREIGN KEY (`far_contact_id`) REFERENCES `civicrm_contact` (`id`) ON DELETE CASCADE,
  CONSTRAINT `FK_civicrm_relationship_cache_near_contact_id` FOREIGN KEY (`near_contact_id`) REFERENCES `civicrm_contact` (`id`) ON DELETE CASCADE,
  CONSTRAINT `FK_civicrm_relationship_cache_relationship_id` FOREIGN KEY (`relationship_id`) REFERENCES `civicrm_relationship` (`id`) ON DELETE CASCADE,
  CONSTRAINT `FK_civicrm_relationship_cache_relationship_type_id` FOREIGN KEY (`relationship_type_id`) REFERENCES `civicrm_relationship_type` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=8191 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.