"Мгновенный" перенос конфигурации

Мгновенный перенос изменений конфигурации между копиями ИБ 8.*


Очень часто при разработке используется несколько копий базы одной конфигурации.

Одна для разработчиков, в которой можно накидать изменения и поверхностно их проверить. Другая для тестеров которые уже набили свои данные и хотят их сохранить при очередном обновлении конфигурации. Другая база с оригинальными данными.. Но вообще вот такой зоопарк имеется у меня.


Дак вот все эти копии для плодотворной работы коллектива приходится обновлять каждый раз когда тестеры натыкаются на очередную по их мнению «не преодолимую ошибку«.

Немного напомню у том как это можно сделать стандартными методами

Есть два пути .. через распределенку, и через Владивосток.

Через распределенку все просто передаем изменения из главного узла в перефирийные.
Чем плох данный способ ..

  • Во первых нужно создавать план обмена.
  • Во вторых каждый раз при создании копии (не начального образа) переопределять главный узел.
  • Ну и читать каждый раз изменения из Xml файла, запуская вначале предприятие и потом конфигуратор.

Ну и через Владивосток это самый распространенный способ:

  1. Выгрузить конфигурацию (УПП 1.2.9 — 5 мин)
  2. Загрузить конфигурацию без сравнения (УПП 1.2.9 — 9 мин).
  3. Обновить конфигурацию (УПП 1.2.9 — 4 мин)

Итого: (5 + 13*n) где n— колличество баз.
О недостатках этого способа нужно говорить?

Есть еще один путь .. пользуюсь им давно не так давно но поражаюсь почему до этого все ходил мимо и не замечал таких простых вещей.

О том как хранятся данные конфигурации писалось давно и много в том числе и мной.
Обратил я внимание на колонку «Modified» в этой колонке сохраняется дата последней модификации записи конфигурации. Вот это основная наша соломинка

Теперь спустимся ну уровень ниже. Для того что передать изменения в конфигурацию нужно сделать записи в Таблицу ConfigSave. При чем не всей конфигурации (как при загрузке без сравнения), а только измененных. Измененной запись будем считать если дата изменения «Modified» ее в основной конфигурации больше чем в копии. Можно еще сравнивать по размеру ну я считаю что это лишнее.
Ну собственно записи добавляем следующим запросом в EM или Enterprise Integrator

В запросе нужно поменять только названия баз соответствующих вашим.

 

 

Имя БД
Описание
dogovor_81 Основная БД из которой передаем изменения конфигурации.
Dogovor81_Test Копия БД в которую нужно передать изменения конфигурации.


 

INSERT INTO Dogovor81_Test.dbo.ConfigSave
Select ConfigNew.* From dogovor_81.dbo.Config as ConfigNew
Left JOIN
Dogovor81_Test.dbo.Config as ConfigOld
ON ConfigNew.FileName = ConfigOld.FileName
Where ConfigNew.Modified>ConfigOld.Modified or ConfigOld.Modified is Null

Выполняем запрос, перечитываем конфигурацию и обновляемся.
Теперь на сладкое… о достоинствах.

  1. Запрос выполняет меньше 2 сек.
  2. Обновление ~~60 сек. записей значительно меньше.
  3. Устраняется колоссальная избыточность перезаписи одинаковых данных.

Ограничения:

  1. Перед выполнением запроса конфигурация в которую необходимо передать изменения должна соответствовать конфигурации БД.
  2. Разумеется только для серверного варианта.




 

12 Comments

  1. artbear

    Красиво 🙂

    ЗЫ блин, похоже, уже пора как-нибудь научиться пользоваться Интегратором 🙂

    Reply ↓
  2. IronDemon

    А что будет при обычном сравнении-объединении после применения твоего способа?

    Reply ↓
  3. awa

    Плюс однозначно! Но вообще-то для описанной ситуации (несколько баз с идентичными конфами) в 1С предусмотрен механизм хранилища, он же средство групповой разработки, он же система контроля версий. Хранилище много удобней и распределенки и уж тем более «Владивостока» 🙂 И в пакетном режиме можно базы обновлять — есть соответствующие ключи командной строки.

    Reply ↓
  4. awa

    Кстати, если в новой конфигурации будет удалён какой-либо объект, например справочник? Насколько я понял из запроса, в обновляемой конфе он останется. Или 1С такую ситуацию отработает правильно?

    Reply ↓
  5. BorovikSV

    Зачем огород городить? Есть же хранилище!

    Reply ↓
  6. German

    (4) все ситуации будут отработаны стандартно.. аналогичны перечислинным вариантам.

    http://groups.google.ru/group/enterprise-integrator/browse_thread/thread/30d2c1b28661ef5f

    Reply ↓
  7. German

    (5) я не против хранилища как раз наоборот, но хранилише в пурвую очередь необходимо для групповой разработки.

    Как раз наооборот для выполнения секудных операций в мне предлагаете подключить базы к хранилишу. а я предлагаю выполнить всего лишь один запрос.

    Reply ↓
  8. Fynjy

    Вот ведь вопрос … При РБД прокатит такой перенос? Там помоему идет метка «изменения отправлены»- «изменения загружены». Или я ошибаюсь.

    ЗЫ: Идея гуд.

    Reply ↓
  9. boggonzikov

    А для postgres подскажите запрос?

    Reply ↓
  10. mrscylla

    boggonzikov порадовал (я случайно зашел в эту тему)

    На дворе 2010 год и «Хранилище конфигурации» и «Сервер хранилища конфигурации»

    😀

    Reply ↓
  11. Трактор

    Жестокий способ. Автор знает толк в извращениях 🙂 А вечерами, наверное, развлекается гуляя по канату на двадцатиметровой высоте без страховки.

    Reply ↓
  12. rasswet

    (9)если узнаете-маякните

    Reply ↓

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *