14.09.2016 13:47
RustamIbragimpv 9 1900 Источник
Вы когда нибудь задумывались, почему вы пишете код на Cache Object Script, а он экспортируется в XML файл?



Так вот, пора меняться. Начиная с выхода новой среды разработки Atelier и версии Cache 2016.2, у вас будет возможность экспортировать и импортировать файлы в формате, в котором вы пишете в студии, так называемый формат UDL (Universal Definition Language). Теперь вы сможете писать код, который не только быстро работает, но еще и приятен глазу в экспортированном виде. Но, возникает другая, не менее важная проблема: если все новые проекты будут находиться в UDL формате, то, кто позаботиться об обратной совместимости?

Давайте начнем


В InterSystems очень серьезно относятся к вопросу об обратной совместимости, поэтому мы решили дать новую жизнь некоторым старым проектам и добавить новую возможность — работа с UDL.

Сравнение
Как понятно на картинке — COS экспортированный в XML, справа — UDL:



Cache Source Control


Первым на очереди стоял довольно-таки простой, но очень полезный проект, который называется Cache Source Control. Его задача очень проста — брать все файлы проекта и экспортировать их в какую то папку после каждой удачной компиляции, а также импортировать новые файлы, которые появляются в папке. До перерождения этот контроль версий мог экспортировать файлы в двух форматах:

  • xml — все файлы имели расширение .xml
  • (cls, mac, int, dfi).xml — все файлы имели расширение .cls.xml и т.д.

Сейчас же достаточно поменять параметр ExpMode на формат UDL для того, чтобы все заработало.

Установка


Для установки достаточно выполнить 4 простых шага:

  • Скачать или клонировать репозиторий
  • Импортировать файл — SourceControl.cls.xml в Studio
  • Открыть портал, зайти в Configuration/Additional Settings/Source Control и выбрать Util.SourceControl, в качестве класса контроля версий в вашей областе
  • Открыть терминал, открыть вашу область и запустить do ##class(Util.SourceControl).Init()

А что, если я хочу сделать экспорт в другую папку?

Решение
Для этого предусмотрено несколько параметров. ..#ExpMode может иметь значения 0, 1, 2 для экспорта в .xml, .cls.xml и в UDL форматах соответственно. Параметр ..#SourceFolder указывает куда сохранять файлы. ..#RefreshTime указывает, через какое количество секунд нужно проверять на наличие новых файлов в папке, чтобы импортировать их.

В принципе, в связке с git этот проект дает все необходимые функции.

CacheUpdater


Следующим проектом в списке на воскрешение стоял CacheUpdater. Его функцию можно отлично понять на примере. Допустим, у вас есть GitHub репозиторий и 100500 серверов, которые его используют. Это будет ночным кошмаром, если вы захотите изменить что-то (Вам везде придется ручками обновлять каждый сервер). Как раз таки эту проблему и решает CacheUpdater — он периодически обновляет локальные файлы, скачивая их с GitHub.

Установка


Его установка немного сложнее:

  • Также скачиваем все файлы
  • Импортировать файл Task.cls.xml в Studio
  • Открыть System Operation/Task Manager/New Task
  • Придумать любое имя таску, выбрать область, в которой вы хотите синхронизировать файлы, выбрать GitHubUpdater как тип таска, ввести данные репозитория и вашего аккаунта на GitHub
  • Нажать Finish
  • Выбрать частоту обновления

Вы готовы к бою, никаких дополнительных настроек производить не нужно.

CacheGitHubCI


Этот же проект является полностью состоявшейся системой для непрерывной интеграции с GitHub.

Установка проекта


  • Достаточно скачать файл Install.cls.xml (если хотите, можно скачать все файлы) и импортировать его в проект

  • Запустить в терминале^

                            Set pVars("Namespace") = "{namespace}" 
                        Set pVars("IP") = "{IP}"
                        Do ##class(CacheGitHubCI.Install).setup(.pVars)

    где, namespace — это область, куда вы хотите установить проект. Если ее нет, то она будет создана автоматически;
    IP — это опциональный параметр вашего сервера(используется для работы webhook).

    Например,

                            Set pVars("Namespace") = "SAMPLES" 
                        Set pVars("IP") = "45.45.45.45:57776"
                        Do ##class(CacheGitHubCI.Install).setup(.pVars)

Готово, для проверки работоспособности хватит. Затем, нужно будет провести такие же манипуляции с созданием Task, как и в CacheUpdater'е. Отлично, все работает! И, наверное, ненароком в голове у вас появился вопрос — «А зачем же мне CacheGitHubCI, если я могу использовать CacheUpdater?».

Ответ
CacheGitHubCI дает возможность указать какие действия должны быть выполнены до и после компиляции, делать unit тесты. Можно настроить webhook'и, чтобы все обновлялось, как только появился новый коммит в репозитории и многое другое. Про то, как настроить все плюшки этой системы, можно прочитать в самом репозитории.

Итог


Пока мы только обновили 3 репозитория. Есть к чему стремится, в списке находится Cache Tort Git, который представляет полноценную работу с git в связке с TortoiseGit.
Поделиться с друзьями
-->

Комментарии (9)


  1. Varkus
    14.09.2016 17:09
    #9807004
    +7

    > Вы когда нибудь задумывались, почему вы пишете код на Cache Object Script, а он экспортируется в XML файл?
    В первые слышу о Cache Object Script, в программировании 16 лет: С, С++, Bash, PHP, JS, HTML
    Может стоило добавить голосовалку, где один из пунктов спрашивает о Cache Object Script? (не сарказм)


    1. morisson
      14.09.2016 18:01
      #9807280
      +2

      В первые слышу о Cache Object Script
      Думаю вы не одиноки в этом. И еще думаю, что в тизере к статье как раз сарказм.


    1. Varkus
      14.09.2016 18:06
      #9807298

      Всё понятно, можно расходиться:
      http://www.sql.ru/forum/507244-1/kto-nibud-ispolzuet-subd-cache

      Как сказал: vv313139
      Прочитал о ней на сайте разработчиков. Красиво расписано. Но тут же на сайте новостей прочитал, что одно «рабочее место» (при >1 пользователях) стоит от 220 уе !?

      Упоминает IBM, но с сожалению, нынче статья недоступна:
      http://www.intersystems.com/casestudies/cache/ibm.html

      Как говорит pullmann:
      Как признался разработчик БД на базе Cache, которая, собственно, и показала многократное превосходство по скорости поиска текстовых строк по шаблону *текст*, все дело в грамотно составленном индексе в конкретной БД (насколько я помню, испытания проводились на примере базы ГАИ).
      На вопрос из аудитории, «почему представители других СУБД не сделали такой грамотный индекс» — он развел руками.
      Выходит, быстродействие достигнуто за счет конкретной реализации БД, а не за счет мега-ультра-быстродействующего движка.

      Опять же, Lepsik:
      проверил в адресной буке IBM — нет там такого человека и никогда не было

      А вот здесь http://www.intersystems.com/ru/our-products/cache/cache-overview/ внезано включилась музыка, от которой я чуть не обосрался, сидя в 4 утра в наушниках и слушая dnb-atmospheric

      Поймите правильно, я честно в первый раз слышу об этой БД, полез почитать в сеть, а там такое…
      Вообщем Петрика вспомнил, нe к ночи будет сказано.


      1. DAiMor
        14.09.2016 18:41
        #9807410

        Кто-то может не понимает что такое Bash, и это значит что в Unix блоге в каждой статье про Bash нужно дать описание, а что это, и опрос добавлять?
        Статья в корпоративном блоге компании разработчика Cache Object Script.
        А откопав сообщения на форуме 8 летней давности, вы считаете можно составить правильное мнение?
        тот же sql.ru имеет отдельный форум по Cache со сложившимся годами сообществом.


        1. playermet
          14.09.2016 21:49
          #9807866

          > со сложившимся годами сообществом
          Судя по числу ответов за последнее время, оно почти мертво.


      1. intersystems
        14.09.2016 23:59
        #9808090

        На sql.ru действительно самый актуальный русскоязычный форум по InterSystems.
        А самая активная англоязычная тусовка сейчас здесь.
        Да, и приходите на митап кстати завтра, если вы в Москве.


  1. doublefint
    14.09.2016 20:52
    #9807706
    +4

    Начиная с выхода… и версии Cache 2016.2, у вас будет возможность ...

    Если мне не изменяет память, класс %Compiler.UDL.TextServices с необходимыми методами появился где то в версии 2014.1
    Так что, скорее — «достаточно давно есть возможность» ;)


    1. RustamIbragimpv
      15.09.2016 11:01
      #9808628

      Да, вы правы. Этот класс существовал еще давно. Однако, %Compiler.UDL.TextServices работает только с классами. Эти же инструменты работают с классами, рутинами, dfi файлами и web.
      Под появлением экспорта и импорта UDL я имел ввиду появление методов $system.OBJ.ExportUDL() и $system.OBJ.Load().
      P.S. Для экспорта и импорты классов мы испульзуем как раз таки %Compiler.UDL.TextServices.


      1. doublefint
        16.09.2016 17:39
        #9812086

        Товарищ ;) Рутины и инклуды можно было экспортировать как простой текст задолго до появления XML.
        DFI даже в «плоском» виде представляют собой XML. Web файлам в базе делать нечего ;) За статью спасибо!