26 апр. 2016 г.

Сохранить имя пользователя и пароль в Git

При работе с приватными репозиториями github, при выполнении операция pull/push git будет постоянно запрашивать имя пользователя и пароль. Заставить систему запомнить введенные один раз значения можно следующим образом:

1. Переходим в окно командной строки, в папку с исходниками

2. Выполняем:

git config credential.helper store

git pull
Username: type your username
Password: type your password

При последующих операциях имя пользователя и пароль вводить уже не надо.

24 апр. 2016 г.

Задание на неделю #1. Firebird 3

Firebird Logo На этой неделе произошло событие, которого мы с нетерпением ждали шесть долгих лет -- вышла третья версия сервера Firebird. В двух словах предыстория такова: Interbase, от которого в 2000-м году отпочковался Firebird, был задуман в те времена, когда многопроцессорные системы с десятками гигабайт оперативной памяти встречались разве что в фантастических рассказах. Когда же научно-технический прогресс догнал и перегнал самые смелые фантазии, именно внутренняя архитектура сервера стала основным тормозом. По сути, в многопользовательском сценарии у системного администратора было два выбора: или использовать оперативную память для кэширования данных, но тогда запросы из всех подключений будут выполняться только на одном процессоре/ядре (архитектура SuperServer), или задействовать все процессоры/ядра, но тогда не будет общего кэша и скорость будет зависеть от производительности дисковой подсистемы (архитектура Classic). Тот случай, когда хрен редьки не слаще.

Изменения в архитектуре SuperServer движка Firebird 3 теперь позволяют последнему выполнять запросы сетевых клиентов параллельно на разных процессорах/ядрах, при доступе к общему кэшу, что теоретически делает SuperServer выбором по умолчанию при развертывании системы на предприятии. Как оно получится на практике -- зависит от надежности тройки. В начале 2000-х мы перевели всех клиентов с SuperServer на Classic по двум причинам: падение процесса SuperServer означает обрыв всех коннектов и потерю данных во всех открытых транзакциях у сетевых пользователей; выполнение тяжелого запроса одним из клиентов практически парализует работу всех остальных.

У одного нашего клиента база данных имеет размер 50 Гб, количество одновременных подключений 50-60, на сервере 128 Гб оперативной памяти и 20 физических ядер. План: использовать SuperServer, установить кэш размером 50 Гб и выделить под буфер сортировки 32 Гб. Учитывая, что дисковая подсистема построена на RAID контроллере с 2 Гб энергонезависимой памяти, теоретически, это позволит вообще исключить прямое обращение к дискам. Т.е. производительность сервера базы данных будет определяться процессором, памятью и скоростью обмена с RAID контроллером.

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

Практически все нововведения из третьей версии найдут применение в Гедымине:

  • Передача НУЛЛ значений по сети битовой маской. Сейчас каждое поле с НУЛЛ значением занимает при передаче 4 байта + длина поля. Например, в таблице с бухгалтерскими проводками у нас десятки полей-аналитических признаков, которые могут быть не заполнены. Экономия может достигать нескольких сотен байт на каждую запись.
  • Возможность увеличить TCP буфер до 32 Кб и применить компрессию данных при передаче. В интернете есть свидетельства о том, что скорость возрастает десятикратно при подключении по сетям с большой латентностью. Например, к серверу в удаленном офисе по VPN каналу.
  • Шифрование файла базы данных. Теперь злоумышленник не сможет получить доступ к конфиденциальной информации просто переписав файл на сервер с чистой установкой Firebird и известным паролем к учетной записи SYSDBA.
  • Window функции в SQL запросах позволяют объединять вместе данные и агрегатные значения по заданным группам этих данных. До Firebird 3 такую задачу можно было решить либо подзапросами (крайне медленно, так как подзапрос будет выполняться для каждой записи), либо выполнением в цикле отдельных запросов для каждой группы и объединением их результатов в единый набор данных с помощью EXECUTE BLOCK или STORED PROCEDURE, либо алгоритмической обработкой на клиенте (например, внутри Fast Report при построении отчета).
  • “Linger” Database Closure for Superserver -- период времени, в течение которого сервер сохраняет в памяти все ресурсы, после закрытия последнего подключения к базе данных -- позволит ускорить загрузку пакета пространств имен, так как переподключение к базе данных выполняется после каждого ПИ, содержащего метаданные.
  • DDL триггеры позволят отказаться от выполнения процедуры at_p_sync при старте системы для синхронизации информации о структуре базы данных с содержимым AT_ таблиц.
  • Другие изменения и улучшения, на которых мы подробнее остановимся в следующих выпусках.
Исходный код Гедымина уже поправлен для совместимости с последней версией. После внутреннего тестирования мы опубликуем подробную инструкцию апгрейда для наших клиентов.

27 янв. 2016 г.

Поиск кольцевых ссылок в реляционной базе данных рекурсивным SQL запросом

Наш предыдущий подход к поиску кольцевых ссылок, изложенный тут, заключался в том, чтобы дать рекурсивному запросу возможность зациклиться и контролировать количество итераций. При достаточно большом их числе мы могли сказать, что скорее всего в данных присутствует цилическая связь. Само число следовало подбирать эмпирически, анализируя данные конкретной задачи.

Между тем, существует способ однозначного выявления циклов без "наматывания" кругов по графу. Рассмотрим граф, показанный на рисунке ниже:

В базе данных он хранится в виде матрицы смежностей в таблице t:

  CREATE TABLE t (
    a INTEGER,
    b INTEGER
  )

Соответственно, исходные данные:

  INSERT INTO t VALUES (1, 2);
  INSERT INTO t VALUES (2, 3);
  INSERT INTO t VALUES (3, 4);
  INSERT INTO t VALUES (3, 5);
  INSERT INTO t VALUES (3, 6);
  INSERT INTO t VALUES (2, 7);
  INSERT INTO t VALUES (6, 1);

Для поиска кольцевых ссылок напишем запрос:

with recursive tree as
  (
    select distinct
      a as initial, a, b, -1 as prev
    from
      t

    union all
    
    select
      iif(tr.initial <> tt.a, tr.initial, -1) as initial,
      tt.a,
      tt.b,
      tr.a as prev
    from
      t tt JOIN tree tr ON
        tr.b = tt.a and tr.initial > 0

  )
select
  *
from
  tree
where
  initial = -1

Запрос покажет все первые сегменты A - B (и предыдущие, т.е. сегменты непосредственно приведшие к циклу, PREV - A), всех возможных циклов в заданных данных. В нашем случае:

INITIAL A B PREV
-1 1 2 6
-1 2 3 1
-1 2 7 1
-1 3 4 2
-1 3 5 2
-1 3 6 2
-1 6 1 3

При необходимости проверить не входит ли в кольцо конкретный узел, следует прописать его ИД в первом запросе рекурсивного CTE:

with recursive tree as
  (
    select distinct
      a as initial, a, b, -1 as prev
    from
      t
    where 
      a = _some_id_

    union all
    
    select
      iif(tr.initial <> tt.a, tr.initial, -1) as initial,
      tt.a,
      tt.b,
      tr.a as prev
    from
      t tt JOIN tree tr ON
        tr.b = tt.a and tr.initial > 0

  )
select
  *
from
  tree
where
  initial = -1

8 янв. 2016 г.

Конвертация параметров складских документов

Параметры складских документов изначально хранились в двоичном поле OPTIONS, в таблице GD_DOCUMENTTYPE.

При наследовании типов документов параметры должны наследоваться. Причем, если мы что-то исправляем в родителе, то изменения должны распространиться на наследника. В обратную сторону распространение работать не должно -- изменили в наследнике, родителя это никак не затрагивает. Реализовать наследование параметров для двоичного формата, во-первых, трудоемко, во-вторых, потребует одномоментной замены всех gedemin.exe на предприятии. Причем минусы в виде непрозрачности данных никуда не денутся.

Новая версия gedemin.exe хранит параметры в реляционном виде в таблице GD_DOCUMENTTYPE_OPTION. Один параметр -- одна запись, связанная с GD_DOCUMENTTYPE.

Для просмотра параметров добавлен грид в окно со списком типов документов.

Правильный порядок конвертации такой:

  1. К эталонной БД, на которой идет разработка, однократно подключаемся из командной строки с параметром /cdo:

    gedemin.exe /cdo

  2. Произойдет автоматическая конвертация опций после чего следует сохранить измененные ПИ.
  3. Грузим обновленные ПИ на базы, где используются складские документы.
Мы прекрасно понимаем, что есть базы предприятий, где нельзя загрузить типовые ПИ без риска утерять изменения, сделанные "по месту". Если на таких базах нет необходимости в настройке параметров складских документов, то можно продолжать работать новым экзешником со старыми (двоичными) параметрами. Если настройка типов необходима, то следует сконвертировать параметры командой gedemin.exe /cdo.

При этом, следует учитывать, что одноименные с параметрами на эталонной базе параметры, при такой конвертации, получат другие РУИДы. В этом нет ничего страшного, если мы не собираемся распространять ПИ с базы предприятия на другие базы. Если же перенос потребуется -- следует загрузить параметры с эталонной БД для того, чтобы переписать РУИДы на типовые.

Последнее верно и для случая, когда разработка ведется на нескольких базах данных. Например, есть база ETALON, где разрабатывается типовой склад, и база ETALON_RESTORAN, где разрабатывается бэк-офис общепита. В этом случае последовательно выполняем:

  1. gedemin.exe /cdo на базе ETALON и сохраняем с нее ПИ.
  2. gedemin.exe /cdo на базе ETALON_RESTORAN и ЗАГРУЖАЕМ на неё общие ПИ с базы ETALON.
  3. Только после загрузки сохраняем ПИ с базы ETALON_RESTORAN.
Конвертация не изменяет двоичных опций в поле OPTIONS. Поэтому в непредвиденных случаях всегда можно вернуться к исходному состоянию просто удалив все записи из таблицы GD_DOCUMENTTYPE_OPTION.

13 дек. 2015 г.

Выполнение скрипт-функции по расписанию

Как организовать выполнение скрипт-функции по расписанию?

Автозадачи решают данную проблему, но требуют постоянно загруженного gedemin.exe и открытого коннекта к базе данных. Начиная с версии 2.9.2 можно использовать планировщик операционной системы и два новых параметра командной строки:

gedemin.exe /run 147000555_256456378

Выполняет скрипт-функцию с заданным РУИДом после загрузки платформы, инициализации подсистемы автозадач и выполнения всех автозадач, назначенных на старт системы (если таковые имеются).

gedemin.exe /run 147000555_256456378 /exit

То же, что и выше, но после выполнения скрипт-функции программа будет завершена.

gedemin.exe /exit

Завершение выполнения gedemin.exe сразу после загрузки, подключения к базе данных, инициализации подсистемы автозадач и выполнения всех автозадач, назначенных на старт системы.

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

14 нояб. 2015 г.

Перезапуск платформы по расписанию

В идеальном мире, где идеальные люди запускают идеальные программы, ошибкам просто нет места. Но в реальной жизни shit, к сожалению, happens. Когда сроки истекли еще вчера, а технические требования заказчик меняет каждый раз, когда видит очередную версию, приходится действовать по методике "run and fire". И, если ошибки на экране в худшем случае заставят пользователя произнести несколько нецензурных слов, то неявные утечки памяти и редкие баги в серверном коде, способны свести с ума даже закаленного аса разработки и отладки.

Здесь на помощь приходит "quick and dirty" решение в виде автоматического перезапуска платформы по расписанию:

На приведенном выше скриншоте показаны настройки автозадачи для перезапуска платформы каждые 10 минут.

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

10 нояб. 2015 г.

Официальный Firebird 3.0 Release Candidate 1

Официальная версия Firebird 3.0 Release Candidate 1 для Windows и Linux (а также исходники) доступна для скачивания на www.firebirdsql.org.

Бета-версия документации по языку Firebird 3.0 находится здесь. Полная версия документации ожидается вместе с релизом Firebird 3.0.

По кулуарным сведениям второй релиз-кандидат будет ориентировочно через месяц. А финальная версия планируется на январь-февраль 2016 г.

9 нояб. 2015 г.

Экспорт в бинарный формат Excel

Начиная с версии 2.9.1 в Гедымине присутствует целых три формата экспорта отчета FR4 в Microsoft Excel.
  • XLS -- экспорт через COM. Требует наличия установленного Microsoft Excel на компьютере, где выполняется построение отчета.
  • XML или XLSX -- запись в текстовый файл данных в XML, в формате SpreadsheetML.
  • BIFF -- запись двоичных данных в файл с расширением XLS. Формат данных -- Excel Binary File Format.

28 окт. 2015 г.

Обратите внимание!

Запуск Гедымина в режиме совместимости с Windows XP SP3 на Windows 10 замедляет работу программы в 2-4 раза. Чем больше операций с памятью, тем больше степень замедления.

Появилось подробное руководство по подбору и конфигурированию железа для сервера Firebird.

Утилита RAMMap позволяет узнать как именно использует оперативную память операционная система. Например, какая часть файла базы данных кэшируется для ускорения обработки. Task Manager показывает такую память как свободную, чем создает впечатление что много памяти Firebird как бы и не надо.

23 окт. 2015 г.

Изменить регистр имени папки в Git

Приключилась ситуация, когда в репозиторий часть файлов записалась в папку Gedemin, а часть -- в gedemin. После этого, на диске во Windows мы видим одну папку -- Gedemin, поскольку операционная система не чувствительна к регистру имен файлов, а в веб интерфейсе github-a -- две. Это не смертельно, но по крайней мере некрасиво. Исправить ситуацию поможет следующая последовательность команд:

git config core.ignorecase false
git mv gedemin tmp
git mv tmp Gedemin
git add -u Gedemin
git commit -m "Changed folder name case"
git config core.ignorecase true

12 окт. 2015 г.

Японцы переизобрели велосипед и выпустили утилиту конвертации БД Firebird:

...на 7 лет позже нашего FDBConvert: