2016-07-15 4 views
2

Я разрабатываю пользовательский код миграции с помощью PHP API вызовов CiviCRM как:миграция данных в CiviCRM - сохранить наследие IdS

<?php 
$result = civicrm_api3('Contact', 'create', array(
    'sequential' => 1, 
    'contact_type' => "Household", 
    'nick_name' => "boo", 
    'first_name' => "moo", 
)); 

Там есть необходимость сохранить оригинальные идентификаторы, но с указанием «идентификатор» или «contact_id» выше, не Работа. Он либо не создает контакт, либо не обновляет существующий. Идентификатор автоматически увеличивается, но MySQL поддерживает вставлять произвольные уникальные значения в этом случае.

Как вы продолжите? Hack CiviCRM каким-то образом передаёт id в MySQL в инструкции INSERT? Как-то сбросить SQL после импорта и манипулировать идентификаторами на месте в текстовом файле .sql (трудно поддерживать целостность)? Любые предложения для этого?

У меня есть ~ 300.000 записей, по крайней мере, для решения, поэтому полностью автоматизированное и надежное решение является обязательным. Любая SQL-магия потенциально может это сделать?

Для тех, кто не знаком с CiviCRM, структура таблицы выглядит следующим образом:

mysql> desc civicrm_contact; 
+--------------------------------+------------------+------+-----+-------------------+-----------------------------+                   
| Field       | Type    | Null | Key | Default   | Extra      |                   
+--------------------------------+------------------+------+-----+-------------------+-----------------------------+                   
| id        | int(10) unsigned | NO | PRI | NULL    | auto_increment    |                   
| contact_type     | varchar(64)  | YES | MUL | NULL    |        |                   
| contact_sub_type    | varchar(255)  | YES | MUL | NULL    |        |                   
| do_not_email     | tinyint(4)  | YES |  | 0     |        |                   
| do_not_phone     | tinyint(4)  | YES |  | 0     |        |                   
| do_not_mail     | tinyint(4)  | YES |  | 0     |        |                   
| do_not_sms      | tinyint(4)  | YES |  | 0     |        |                   
| do_not_trade     | tinyint(4)  | YES |  | 0     |        |                   
| is_opt_out      | tinyint(4)  | NO |  | 0     |        |                   
| legal_identifier    | varchar(32)  | YES |  | NULL    |        |                   
| external_identifier   | varchar(64)  | YES | UNI | NULL    |        | 

и мы говорим о первом поле.

+0

Обратите внимание на будущий вопрос о том, что CiviCRM имеет собственный сайт для стека - http://civicrm.stackexchange.com/ – samuelsov

ответ

0

Вы должны использовать поле external_identifier, которое выполняется именно так, как вы хотите.

Это поле не используется самим CiviCRM, поэтому нет никакого риска столкнуться с функциональностью ядра. Это делается для связи с внешней системой (например, для наследия).

CiviCRM считает внешний_идентификатор уникальным, поэтому он будет вызывать ошибку (используя API - я думаю) или обновлять (используя экран импорта контактов CiviCRM), если вы попытаетесь вставить контакт с тем же внешним_источником.

+0

Спасибо за это, это определенно хорошее направление, моя единственная проблема в том, что мне нужно будет подать заявку это также для вкладов, которые не имеют этой области. Конечно, это возможность предоставить патч для CiviCRM для внешнего ID для всех (много?) Объектов. –

+0

В этом случае я предлагаю вам создать настраиваемое поле для вклада, хранящего этот внешний идентификатор. – samuelsov

Смежные вопросы