Автоматическое документирование базы данных

Для документирование базы данных применяется открытое решение Autodoc.

Инструкция по установке и настройке на сайте appcode.pw

Основной скрипт для запуска генерации документации.

cd autodoc
postgresql_autodoc -d cic-dev-db -h 192.168.17.111 -u postgres --password=<pw> -t html -s "core|dbo" -f /var/www/html/cic-dev-db

Демонстрационный вариант документации можно посмотреть на сайте http://cic.it-serv.ru/cic-dev-db.html

Интеграция

Информация актуальна для пилотной версии МРСК ЦиП на 08.10.2020

В пилотной версии МРСК ЦиП информация может быть импортирована в следующие таблицы:

  • dbo.ed_input_meter_readings — текущие контрольные показания
  • dbo.ed_registr_pts — точки учета
  • dbo.ed_device_types — типы прибора учета

Примечание: информацию по таблицам можно посмотреть тут

Точка учета

Информация о точках учета должна храниться в таблице dbo.ed_registr_pts. Здесь может храниться любая информация, но при этом должны быть заполнены следующие поля:

  • c_address: text — полный адрес
  • n_longitude: numeric — долгота
  • n_latitude: numeric — широта
  • f_division: integer — филиал/отделение
  • f_subdivision: integer — участок

Показания

Информация о показаниях храниться в двух таблица:

  • dbo.ed_input_meter_readings — входящие показания. Первоначальные показания в нашей системе. Если показания и дата неизвестны, то можно указать null. При этом информация о тарифной зоне и разрядности должна быть указана обязательно.
  • dbo.ed_output_meter_readings — исходящие показания, результат обхода.

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

-- пример наличия первичных показаний
INSERT INTO dbo.ed_input_meter_readings(f_point, n_value_prev, d_date_prev, n_digit, f_time_zone, f_registr_pts, n_tariff)
VALUES ('b17c5973-615c-49c6-976f-7a491a41a160', null, null, 5.0, 2, '028d65a4-3621-408b-af0a-230242f41702', 1); -- создано показание с тарифом 1 и показанием "Сутки"

INSERT INTO dbo.ed_output_meter_readings(fn_meter_reading, fn_point, fn_route, fn_user_point, n_value, d_date)
VALUES ('394fb071-7d9f-4c13-ada6-3c45b0f1643b', 'b17c5973-615c-49c6-976f-7a491a41a160', 'c68b1a77-0a13-4c05-bc3e-c2504868f0ac', '547c39bd-d171-4cae-bf64-c30fae16210a', null, '2020-05-01');

Алгоритм обработки показаний тут.

Работа с WebSocket

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

Передача уведомлений осуществляется при помощи «пакетной» передачи данных — механизм аналогичный синхронизации.

NML175.........0{"stringSize":29,"binarySize":0,"attachments":[],"bufferBlockToLength":207,"bufferBlockFromLength":0,"transaction":false,"dataInfo":"mail","version":"v2","id":"1599022001522"}[{"name":"to0","length":207}]{"action":"cd_notifications","method":"Add","data":[[{"fn_user_to":null,"fn_user_from":null,"c_message":"Hello","c_title":"Уведомление","d_date":"2020-09-02T04:46:39.785Z"}]],"tid":0,"type":"rpc"}

Выше показан пример пакета для отправки уведомлений.

Создание слушателя в NodeJS

Переходим в каталог modules/socket и находим там файл main.js В этом файле выполняется регистрация нового слушателя.

Файл для регистрации слушателя
Читать далее «Работа с WebSocket»

Механизм хранения ошибок от клиентских приложений

Для хранение клиентских ошибок от клиентских приложений используется нижеуказанная таблица.

sd_client_errors

  • id: uuid — первичный ключ;
  • c_message: text — текст ошибки;
  • c_code: text — код ошибки;
  • d_created: timestamp with time zone — дата возникновения ошибки на клиенте;
  • fn_user: integer — идентификатор пользователя чьё приложение вызвало ошибку;
  • c_version: text — номер версии;
  • c_platform: text — тип платформы, например, Android, iOS, Sailfish OS;
  • jb_data: jsonb — Прочая информация. Например: ОС, версия, Архитектура или модель и т.д.;
  • dx_date: timestamp with time zone — Дата сохранения на сервере. Вычисляется при вставке;
Читать далее «Механизм хранения ошибок от клиентских приложений»

Чтение серверных настроек

Для чтения настроек доступна удаленная функция PN.setting.getSettings

Данная функция вернёт объект настроек предназначенный для пользователя, который был авторизован в системе.

Пример запроса

[{
"action": "setting",
"method": "getSettings",
"data": [{ "params": ["MBL_"] }],
"type": "rpc",
"tid": 1
}]
Читать далее «Чтение серверных настроек»

Peer authentication failed for user

Если при сохранении файла (cf_save_file) выдается ошибка

could not connect to server "fs"
Peer authentication failed for user "mobnius"

то нужно перейти на сервер и изменить настройки pg_hba.conf

Все значения peer заменить на md5.

Примечание: для пользователя postgres менять не нужно.

Читать далее «Peer authentication failed for user»

b_current и b_check

Некоторые таблицы содержать две колонки:

  • b_current: boolean – текущая актуальная запись для одного элемента object_id;
  • b_check: boolean – подтвержденная запись, была проверена диспетчером или пользователь является доверенным.

АЛГОРИТМ ПРИМЕНЕНИЯ ПОЛЕЙ

  • b_current проставляется только после установки b_check – диспетчер подтверждает результат работы, говоря тем самым, что запись является последней актуальной;
  • для нескольких записей в рамках одной точки (см. object_id) b_current может быть установлен, только у одного;
  • по установленным значениям b_check можно просматривать историю точки.

HTTP-сервис

При добавлении новых таблиц/представлений/функций требуется перезапускать серверное приложение на сервере. Эта возможность позволит серверному приложению перестроить внутреннюю схему базы данных. Если эта операция не будет выполнена, то вызов новых RPC функций будет не доступен.

sudo stop mobnius
sudo start mobnius