Как удалить пропуск в зону ато из базы данных: Как удалить пропуск в зону АТО (ООС). СТАРЫЙ, с ошибками, неправильно заполнено Ф.И.О или серия

Whatnew — АВТОМАРШАЛ — Mallenom Systems

Что нового? ПО Автомаршал — Изменения

• 2022
  • 2.26.0 — 10.04.2022
• 2021
  • 2.25.3 — 02.12.2021
  • 2.25.0 — 10.11.2021
  • 2.24.1 — 09.08.2021
  • 2.24.0 — 30.07.2021
  • 2.23.3 — 05.03.2021
  • 2.23.2 — 04.03.2021
  • 2.23.1 — 02.03.2021
• 2020
  • 2.23.0 — 26.12.2020
  • 2.22.5 — 26.11.2020
  • 2.22.4 — 06.11.2020
  • 2.22.3 — 06.10.2020
  • 2.22.1 — 17.09.2020
  • 2.21.3 — 13.05.2020
• 2019
  • 2.20.0 — 05.12.2019
  • 2.19.1 — 21.10.2019
  • 2.19.0 — 19.09.2019
  • 2.18.1 — 05.08.2019
  • 2.18.0 — 11.07.2019
  • 2.17.8 — 23.04.2019
  • 2.17.7 — 22.04.2019
  • 2.17.6 — 17.04.2019
  • 2.17.5 — 15.04.2019
  • 2.17.4 — 08.04.2019
  • 2.17.3 — 28.03.2019
  • 2.17.2 — 28.03.2019
  • 2.17.1 — 26.03.2019
  • 2.17.0 — 25.03.2019
  • 2.16.3 — 14.02.2019
  • 2.16.2 — 31. 01.2019
  • 2.16.1 — 31.01.2019
  • 2.16.0 — 29.01.2019
• 2018
  • 2.15.1 — 19.11.2018
  • 2.15 — 12.11.2018
  • 2.14.1 — 07.09.2018
  • 2.13.2 — 20.08.2018
  • 2.13.1 — 13.08.2018
  • 2.13.0 — 01.08.2018
  • 2.12.1 — 14.06.2018
  • 2.11.10 — 14.05.2018
  • 2.11.9 — 23.04.2018
  • 2.11.8 — 20.04.2018
  • 2.11.4 — 17.04.2018
  • 2.11.3 — 17.04.2018
  • 2.11.1 — 10.04.2018
  • 2.10.10 — 22.02.2018
  • 2.10.9 — 16.02.2018
  • 2.10.5 — 12.02.2018
  • 2.9.7 — 15.01.2018
• 2017
  • 2.9.6 — 29.12.2017
  • 2.9.5 — 22.12.2017
  • 2.9.3 — 21.12.2017
  • 2.8.3 — 10.11.2017
  • 2.7.3 — 16.10.2017
  • 2.6.0 — 01.09.2017
  • 2.5.6 — 18.08.2017
  • 2.5.5-2 — 14.08.2017
  • 2.5.5 — 31.07.2017
  • 2.5.4 — 29.06.2017
  • 2.5.3 — 31.05.2017
  • 2.5.2 — 26.04.2017
  • 2.5.1 — 24.04.2017
  • 2.5.0 — 20.02.2017
• 2016
  • 2.4.5 — 16. 11.2016
  • 2.4.4 — 20.10.2016
  • 2.4.3 — 18.10.2016
  • 2.4.2 — 06.10.2016
  • 2.4.1 — 03.08.2016
  • 2.4.0 — 04.07.2016
  • 2.3.1 — 23.05.2016
  • 2.3.0 — 19.04.2016
  • 2.2.0 — 19.02.2016
  • 2.1.1 — 25.01.2016
• 2015
  • 2.1.0 — 30.12.2015
  • 2.0.10 — 27.11.2015
  • 2.0.9 — 17.11.2015
  • 2.0.8 — 02.11.2015
  • 2.0.7 — 26.10.2015
  • 2.0.6 — 22.10.2015
  • 2.0.5 — 16.10.2015
  • 2.0.4 — 12.10.2015
  • 2.0.2 — 23.09.2015
  • 2.0.1 — 16.09.2015
  • 1.56.1 — 23.09.2015
  • 1.55.4 — 18.09.2015
  • 1.55.3 — 10.09.2015
  • 1.55.2 — 09.09.2015
  • 1.55.0 — 07.09.2015
  • 1.54.1 — 03.09.2015
  • 1.54.0 — 01.09.2015
  • 1.53.2 — 25.08.2015
  • 1.53.1 — 20.08.2015
  • 1.53.0 — 09.08.2015
  • 1.52.0 — 07.07.2015
  • 1.51.6 — 15.07.2015
  • 1.51.5 — 11.06.2015
  • 1.51.3 — 05.06.2015
  • 1.51.1 — 02.06.2015
  • 1.50.3 — 14.05.1015
  • 1. 50.0 — 08.05.1015
  • 1.49.0 — 26.03.2015
  • 1.48.2 — 18.02.2015
  • 1.48.1 — 17.02.2015
  • 1.47.4 — 10.02.2015
  • 1.47.2 — 02.02.2015
  • 1.47.1 — 15.01.2015
  • 1.47.0 — 15.01.2015
• 2014
  • 1.46.13 — 22.12.2014
  • 1.46.10 — 12.12.2014
  • 1.46.7 — 05.12.2014
  • 1.46.7 — 05.12.2014
  • 1.46.6 — 03.12.2014
  • 1.46.5 — 20.11.2014
  • 1.46.4 — 20.11.2014
  • 1.46.3 — 18.11.2014
  • 1.46.2 — 17.11.2014
  • 1.46.1 — 14.11.2014
  • 1.45.9 — 12.11.2014
  • 1.45.8 — 31.10.2014
  • 1.45.6 — 29.10.2014
  • 1.45.5 — 16.10.2014
  • 1.45.4 — 16.10.2014
  • 1.45.2 — 13.10.2014
  • 1.44.1 — 06.10.2014
  • 1.44.0 — 02.10.2014
  • 1.43.0 — 26.09.2014
  • 1.42.1 — 05.09.2014
  • 1.42.0 — 01.09.2014
  • 1.45.0 — 13.10.2014
  • 1.44.1 — 06.10.2014
  • 1.44.0 — 02.10.2014
  • 1.43.0 — 26.09.2014
  • 1.42.1 — 05.09.2014
  • 1.42.0 — 01.09.2014
  • 1. 41.4 — 29.08.2014
  • 1.41.3 — 27.08.2014
  • 1.41.2 — 18.08.2014
  • 1.41.1 — 13.08.2014
  • 1.40.4 — 04.08.2014
  • 1.40.3 — 31.07.2014
  • 1.40.2 — 21.07.2014
  • 1.40.1 — 08.07.2014
  • 1.34.5 — 02.06.2014
  • 1.34.4 — 20.05.2014
  • 1.34.3 — 15.05.2014
  • 1.34.2 — 06.05.2014
  • 1.34.1 — 05.05.2014
  • 1.34.0 — 01.04.2014
  • 1.33.0 — 12.03.2014
  • 1.32.0 — 20.02.2014
  • 1.31.0 — 19.02.2014
  • 1.30.0 — 12.02.2014

2.26.0 — 10.04.2022¶

• Добавлено распознавание Евросоюза (#29298)
• Добавлено распознавание Китая (#29227)
• Улучшено распознавание РФ (#29227)
• Добавлена модель распознавания спецтранспорта (#28943)
• Добавлено в события «Номер распознан» и «Номер записан в журнал распознавания» опция по типу спецстранспорта (#29334)
• Добавлено совместимость Экспорт HTTP со всеми событиями активации триггера (#28858)
• Модуле Передний Задний Номер реализован учет времени пребывания для заднего номера (#29261)
• Модуль Передний Задний Номер. Добавлена передачу id записи переднего и заднего номера (#29253)
• Добавлены в событие «Номер ТС записан в журнал распознавания» группы пользователей (#29333)
• Добавлено событие активации «Запись отредактированна»(#29219)
• Добавлен выбор видеоканала в событие активации «Длительность пребывания превышена» (#29028)
• Реализована поддержку функции «Не учитывать номер региона» для метода распознавания LPRNet (#29056)
• Добавлен фильтр в планировщике задач БД (#29070)
• Убрано ограничение в 10 тыс. записей при создании отчетов через АМ (#28084)
• Добавлен перенос номера из одного списка в другой со всеми доп. полями (#29306)
• Модуль Numpass. Добавлена кнопка с выбором буквенного кода страны (#29075)
• В Планировщике БД добавлено удаление записей с фильтрацией по списку(#28903)
• Поле «Статуса пропуска» (истек, активен) теперь учитывает пропуска, которые еще не начал действовать. (#27898)

• Добавлена возможность изменять размер окна Поиска ТС в списке F6 (#29197)

• отключена по умолчанию галочку HTTPS для модуля NxWitness (#29114)

• Исправлено зависание при создании быстрого отчёта по пользовательскому шаблону(#29125)

• Изменен интерфейс планировщика задач (#29348)

• Исправлены ошибки (#29330, #28984, #29234, #28083, #29165, #29277, #29312, #29325, #29222, #29078, #28520, #28975, #29096, #29106, #29110, #29131, #28203, #27534, #29012, #29055, #29058, #29130, #29176, #29136)

Web-Client.

• Реализована возможность пользователям web клиента перезаписывать список без права создавать (#28854)
• Добавлено описание шаблонов часов доступа пропуска, в web client (#28788)

Дорожный пристав.

• Дорожный пристав. Модуль Розыск. Убран цвет в настройках списка (#28947)

АМ Gate

• Модуль Gate. Убрана «i» из распознавания (#29202)
• Модуль Gate. Добавлена поддержка спецтранспорта (#29284)

2.25.3 — 02.12.2021¶

• Улучшена совместимость метода распознавания Стандарт и локализации номера YOLOLocalization

2.25.0 — 10.11.2021¶

• Добавлены новые модели нейронных сетей (#28599, #28483, #28603, #28674)
• Модуль Зоны контроля. Добавлена возможность присвоить автомобилю определенное место (#26950)
• Модуль Зоны контроля. Добавлена возможность вывести состояние зон контроля (#26951)
• Модуль Зоны контроля. Добавлены события активации триггеров для Модуля Зоны Контроля (#28782)
• Добавлено условия срабатывания триггера — Осталось свободных мест на территории (#27434)
• Добавлена функция удаления записей со сроком создания свыше X дней для заданного списка (#28083)
• Добавлено в окно настройки Ручная Регистрация ТС возможность отключить подтверждение действий пользователя на редактирование записи (#28703).
• Модуль Sigur. Добавлена передача распознанного номера с группы камер в Sigur (#28232)
• Добавлена в триггеры информация о совместимости событий активаций, условий и действий (#28783).
• Добавлено в конфигуратор отчетов изображение с обзорной камеры (#26022).
• Добавлено Событие активации Триггера, если длительность пребывания больше лимита (#27551)
• Добавлен допуск авто по номеру и по карточке (#15696).
• Добавлена возможность экспортировать и импортировать Пользователей в xml (#28507).
• Добавлена возможность переноса записи по триггеру (#27252).
• Добавлена отправка сообщений в модуле телеграмм в конкретный чат (#28580).
• Добавлена возможность обновлять значения доп.полей в журнале (#28611).
• Обновлен Модуль интеграции с Numpass (#28618)

• Добавлена программное измерение скорости в Автомаршал (#28808)

• Исправлены ошибки (#26098, #27658, #28653)

• Исправлена проблема сбрасывания фильтра по списку в триггерах при экспорте/импорте списка (#28677).

h3. Web-Client.

• Добавлена возможность задавать направление движения в окне ручной регистрации ТС в ВЕБ клиенте (#28544)
• Исправлена проблема, когда при изменении триггера (даже названия) отваливается кнопка триггера поверх потока в веб-клиенте (#27586).

2.24.1 — 09.08.2021¶

• Исправления в модуле Передний Задний номер

2.24.0 — 30.07.2021¶

• Модуль Экспорт HTTP. Добавить возможность гибкой настройки запросов (#27550).
• Добавить поддержку распознавания номеров Республики Южная Осетия (#27508).
• Добавлено локальное хранение пропусков из Claris на сервере с Автомаршал (#27828).
• Добавлено Автоматическое создание записи на выезд для авто с направлением Въед без выезда по таймеру (#27840).
• Модуль Telegram переведен на триггеры (#16264).
• Модуль Планировщик задач БД. Удаление номеров из списка при удалении пропуска через планировщик задач (#27731).
• Добавлен модуль интеграции с Sigur (#21985).
• Модуль Экспорт HTTP. Добавить возможность ответа на запрос. Добавить событие активации в триггеры (#16497).

• Модуль Радар. Добавить событие активации триггера «Превышена скорость ТС» (при интеграции с радаром) (#27881).

• Web-Client. Добавить логирование в журнале действий пользователя удаление и добавление номера в список через ВЕБ клиент (#27604).

• Web-client. Пометить удаленные списки (#28290).

• Web-Client. Добавить название редактируемого списка (#27644).

• Web-Client. Добавить в WEB клиенте фильтр по статусу пропусков (#25628).

*Исправлены ошибки (#27890, #28225, #22302, #26944, #28081, #28228, #27414, #26875)

• Web-client. При импорте списка задается шаблон с пропуском 1 минута (#28105).
• Web-Client. Не работает отображение всех записей в Журнале. (Удалены пропуска у записей) (#26877).
• Web-client, ломается отображение журнала (#27382).
• Web-client. В Журнал распознавания не выводится значение доп. полей (#27656).
• Web-client. Значения доп. полей переходят между собой при добавлении нового доп. поля (#27665).
• Web-client Неправильное отображение пользователя, кем созданна запись в списке (#27975).
• Web-client. В firefox можно руками менять шаблон пропуска (#28016).
• Web-Client. При импорте списка неверно отображается значение полей (#27899).
• Web-Client. Ошибка при загрузке записей списка при высоком разрешении экрана 2560×1440 (#28080).

2.23.3 — 05.03.2021¶

• Исправлена ошибка настройки распознавания

2.23.2 — 04.03.2021¶

• Исправлены ошибки в Web-client (#27918)

2.23.1 — 02.03.2021¶

• Добавлен Onvif
• В модуль Экспорт HTTP добавлена возможность отправлять параметры в строке url (#27876)
• Добавлена возможность печатать квитации 6см из панели деталей (#27155)
• Добавлена интеграция со СКУД Sigur (#21985)
• Добавлен новый детектор номерный пластин YOLOLocalization (#27896)
• Исправлены ошибки (#25238, #27031, #26775, #27649, #26370, #27205, #27758, #27754, #27725, #27778, #27761, #27383, #27372, #27739, #26477)
• Исправлены ошибки (#21329, #27413, #27666, #27760, #27660, #27862, #27760, #21985, #27896, #27739)

2.

23.0 — 26.12.2020¶

• Реализованы «Группы пользователей» для работы со списками (#23711)
• Добавлен новый тип проезда по 4 индукционным петлям (#27413)
• Обновлена предобработка видео (#27327)
• Добавлена возможность отправлять распознанный номер в теме письма (#27259)
• Добавлено событие активации «Детекция движения» на видеоканале (#27336)
• Добавлена возможность вывода сообщения в окне уведомления (#26978)
• Улучшено окно быстрого добавления номера в список (#27298)
• Добавлена кнопка сохранения изменений в окно редактирования записи (#27031)
• Добавлена настройка приоритета видеоканала для отображения кадра распознавания (#25888)
• Добавлена очистка БД через исполняемый .bat файл (#27232)
• Добавлено поле «Точность распознавания» в отчеты (#27335)
• Добавлена возможность редактировать тело HTTP-сообщения для модуля Экспорт HTTP (#27336)
• Web-Client: реализована перезапись существующих в БД списков при импорте (#26853)
• Web-Client: добавлена возможность перезаписи пропуска авто для обычного списка (#26370)
• Исправлены ошибки (#26856, #26875, #26856, #27240, #27306, #27539, #27076)

2.

22.5 — 26.11.2020¶

• Исправлена интеграция с NX Witness и SeficaProbox (#27539).
• Обновлена интеграция с Numpass (#27357).
• Добавлено событие активации триггера «Событие проверки оператора» (#27408).
• Обновлен Модуль AutogardParking (#27412, #27409).
• Исправлено сохранение настроек распознавания (#27453).

2.22.4 — 06.11.2020¶

• Добавлено событие активации триггера детекция движения (#27336).
• Изменен интерфейс и исправлены ошибки в окне Настройки шаблоны строки (#27336).
• Добавлена возможность редактировать тело HTTP-сообщения для модуля Эскпорт HTTP (#27336).
• В конфигуратор отчетов добавлена точность распознавания (#27335).

2.22.3 — 06.10.2020¶

• Обновлен видеоисточник ffmpeg.
• Исправлена ошибка модуля Радар (#27209).
• Исправлено отображение номера при выезде (#27189).
• Исправлен импорт/экспорт списков в модуле Розыск (#27177).

2.22.1 — 17.

09.2020¶

• Улучшено распознавание номеров Польши (#26519)
• Улучшено распознавание номеров Гонконга (#26224)
• Добавлен классификатор типов транспортных средств (#26100)
• Добавлен новый тип видеоканала для мониторинга парковок (#26831)
• Добавлен модуль «Зоны контроля» (#15471)
• Добавлен модуль с новым протоколом AUTOGARD (#26541)
• Добавлена интеграция с Numpass (#26569)
• Добавлена поддержка устройств ввода-вывода ADAM и возможность подключения устройств по протоколу Modbus TCP (#26577)
• Доработана квитанция за парковку (#26395)
• В настройках предобработки видео добавлена сетка (#24941)
• В справке добавлено окно с описанием горячих клавиш (#20086)
• Изменен формат времени на 24-часовой в модуле VECTOR_AP (#26263)
• Добавлено окно “Последний номер” в Автомаршал.Gate (#23830)
• Web-Client: В WEB API добавлен параметр «Confidence» (#26641)
• В Дорожном приставе заблокирован неиспользуемый функционал (#26493)

2.

21.3 — 13.05.2020¶

• Добавлено распознавание номеров Косово (#25218).
• Улучшено управление zoom’ом в окне редактирования записи (#25021, #22784)
• Добавлена настройка автообновления журнала распознавания (#25066)
• В журнал распознавания добавлен фильтр «За последние 60 / 90 дней / за все время» (#24261).
• Добавлена пометка отредактированных пользователем записей в журнале распознавания (#21323)
• Добавлена возможность поиска ТС у водителя ( #24980)
• Добавлено автообновление парковочных мест в окне «Парковка» (#24899)
• Добавлено условие срабатывание триггера: «Осталось свободных мест на территории» (#24928)
• Реализовано управление освещением на основании геоинформации (#9729).
• Добавлена отправка отчета на Яндекс.Диск и Google Диск (#12507).
• В конфигуратор отчетов в источники данных добавлен срок действия пропуска (#24412).
• Добавлен массовый перенос записей из списка (#23690)
• При экспорте данных на диск добавлена возможность сохранять фото со связанных видеоканалов (#21264)
• Добавлена миграция данных для СУБД SQL Server и Postgres (#23745)
• В справку о программе добавлена подробная информация о текущем сервере АМ (#25280)
• Добавлен модуль интеграции с радаром DAHUA DHI-ITARD-024SA (#24947)
• Добавлен новый модуль ProxWay (#25661)
• Добавлен модуль “Проверка оператора на рабочем месте” (#11990).
• Модуль “Стоп-линия”: Добавлена возможность настройки отображения стоп-линии на фото и записи видео до пересечения стоп-линии (#25656, #24077)
• Mодуль VectorAP: Добавлена возможность настраивать метод обнаружения ТС в (#25502)
• Модуль “Тарификация”: Добавлена квитанция на листе 6см и автоматический вывод на печать без подтверждения во всплывающем окне (#25330, #25367).
• Убран модуль СФИНКС (#24900)
• Обновлена интеграция с Pass24.Online (#25297)
• Добавлены теги для переменных и входов/выходов (#25833).
• Web-клиент: добавлено отображение количества свободных мест (#19019)

2.20.0 — 05.12.2019¶

• Добавлены новые шаблоны Польши (#24791, #24857).
• Доработать Экспорт данных через HTTP (#24368).
• Учитывать идентификатор смарт-карты при считывании (#22754).
• Добавление номеров Туркменистана (#22027, #21713).
• Добавить мониторинг размера БД и оповещение при превышении 9-10Гб текстовой информации (#22310).
• Добавить PostgreSQL в инсталлер Автомаршала (#23931).
• Поддержка PostgreSql в Automarshla (#23744).
• Ограничить доступ к Database manager (#21849).
• Резервное копирование и восстановление базы данных PostgreSql (#24161).
• Добавить настройку подключение PostgreSQL в инсталер Automarshal Web Client (#24479).
• Добавить поддержку прокси в модуле Telegram (#22894).
• Модуль считыватель карт. Интеграция с адаптером Z2-Base (#24332).
• При закрытии АМ спрашивать «Действительно хотите закрыть программу? (#21829).
• Связывать Въезд и Выезд если есть различия в регионе и включено «Не учитывать регион» (#22903).
• Добавить ярлык Автомаршала с включенным OpenGL (#24497).
• Модуль RS232/RS485. В отправку сообщения добавить инф-ию о том как был распознан номер: вручную или автоматически (#24564)
• Смарт-камера. Ускорить процесс распознавания со смарт-камеры (#23861).
• Модуль «Передний и задний номер». Добавлен проезд для парковки (#24343).
• Исправлены ошибки(#18450, #23835, #17706, #18279, #22457, #24423, #23997, #23998, #24023, #24045, #24207, #24445, #22998).
• Исправлены ошибки(#23957, #24004, #24073, #24074, #24136, #23942, #24015, #24016, #24046, #24089, #24166, #24179, #24567, #24349)
• Добавить в сервисе распознавания поддержку Syslog (#24240).
• Добавить в сервисе распознавания поддержку RabbitMQ (#24241).
• Добавить в сервисе распознавания Basic авторизацию (#24242).
• Добавить группировку каналов в сервисе распознавания (#24243).
• Написать плагин интергации с Облачным сервисом (Pass service) (#23963).
• Модуль управления устройствами. Добавлена поддержка LAN Relay Switch RS-201 (#24628).

2.19.1 — 21.10.2019¶

• Модуль Pass24. Добавлена синхронизация базы пропусков Pass24 c АМ (#21800).
• Модуль Передний и задний номер. Добавлена опция определения направления движения по датчикам (#24044).

• Модуль Считыватель карт. Добавлена возможность присваивать карты записям к списках (#22754).

• Исправлены ошибки(#24045, #22998, #23942, #18279 #24023 #24015 #24089 #23997 #23998 #22754 #24179 #24207 #23861 #24349, #23977).

2.19.0 — 19.09.2019¶

• Добавить альтернативную возможность получения потоков из ПО Линия #H.264 (#14771).
• Доработка модуля передний и задний номер (#22888).
• Добавить устройство управление Эмулятор и окно тестирования устройства (#23607).
• В триггерах реализована передача аргументов в исполняемый файл (#22094).
• В интеграции с Nx Witness (v3 и v4) реализован механизм синхронизации с видеоисточниками AM, в Nx Witness теперь отображается картинка с камеры (#23409).
• Добавлена возможность ежемесячной рассылки отчетов в указанное число месяца и время (#23285).
• В ингеграции с СКУД Gate добавлен новый алгоритм кодирования номера в 5 байт (Code5Bytes) (#21715).
• Добавлено автоматическое установление связи въезда и выезда после редактирования записи в журнале распознавания (#22532).
• В Telegram боте реализована возможность передачи нескольких фотографий со связанных камер одним сообщением (#22816).
• Интеграция со смарт-камерами Sunell, сохранение результатов распознавания в AM (#22912).
• Добавлен групповой экспорт пользовательский списков(#21736).
• Добавлен групповой импорт пользовательский списков(#22892)
• Web-клиент: добавлена возможность скрытия кнопки «пропуск» в списке (#22611).
• Web-клиент: добавлена сортировка записей в журнале и в списках (#22116).
• Web-клиент: добавлена возможность делать обязательные к заполнению поля у записи списка (#18130).
• Добавлена возможность изменить язык (#23090).
• Исправлены ошибки (#23480, #23598, #23609, #21924, #22041, #23117, #23852, #23882).
• Оптимизация открытия окна «Редактирование пользовательских списков»(#23398)

2.18.1 — 05.08.2019¶

• Добавлен модуль «RFID-считыватели» (#13012, #22833, #22879, #23294).
• Исправлены ошибки (#22935, #23004, #23163, #23144, #23145, #23168, #23248, #23271, #23270, #23267, #23168, #23256, #23258, #23259, #23039, #23301, #23315, #23313, #23249, #23032, #23306, #23305, #23316, #23314, #23324, #23316, #23313, #23305, #23032, #23341, #23251, #23308, #23365, #22833, #23353).

2.18.0 — 11.07.2019¶

• Добавлены номера Ирландии, Черногории, Вьетнама (#21147, #21745, #17604).
• Переделан модуль Розыск (#19825).
• Добавлен модуль «Cчитыватели карт» (#21870).
• Добавлен модуль «Контроль ОСАГО» и переименован модуль «Экспорт для ЦАФАП» в «Контроль стоп-линии» (#22372).
• Добавлено действие в триггеры «Запись видео»(#19896).
• Добавлены шаблоны триггеров (#21556).
• В триггерах в событии активации «Обнаружено ТС» добавлено условие «Проверять решения созданные триггером» (#22338).
• Добавлена возможность добавлять и переопределять языки АМ (#22678, #22602, #22732).
• Добавлена возможность ручного распознавания на видеоканалах видеонаблюдения (#22840).
• Новый механизм видеозаписи (#22665).
• Добавлена поддержка OpenGL, улучшена производительность (#22923).
• Добавлен параметр командной строки, отключающий OpenGL (#22642).
• Обновлен интерфейс настроек связей со справочниками (#22315).
• Обновлен интерфейс дополнительных полей (#22314).
• Обновлен интерфейс справочников (#21534).
• Переработана настройка территорий (#21578)
• Восстановлен модуль CleanControl в AM.Gate (#22285).
• Web-клиент: ограничено максимальное количество записей в отчёте (#22021).
• Web-клиент: добавлена кнопка переключения языка на странице входа (#21597).
• Web-клиент: добавлен поиск по записям на странице редактирования списка (#21363).
• Web-клиент: добавлен тег состояния записи журнала в зависимости от состояния пропуска (#20968).
• Web-клиент: добавлена пометка удалённых списков в фильтре журнала (#20883).
• Web-клиент: выполнена сортировка номеров в списках по дате добавления (#20029).
• Добавлена передача достоверности распознавания в модуле интеграции с VECTOR_AP (#21502).

• Web-клиент: добавлено разграничение доступа к спискам (#18521).

• Исправлены ошибки (#19063, #21284, #21993, #22778, #22796, #19630, #20195, #22395, #22396, #22398, #21461, #21547, #22339, #22643, #22821, #22830, #21186, #21258, #21934, #22092, #22130, #22223, #22224, #22510, #22661, #22725, #22790, #20898, #22486, #22695, #22478, #22911, #22868,#22868, #22842, #22668, #22618, #22523, #22015, #22014, #21967, #22485, #22655, #22795, #22865, #21401, #21589, #22864, #21952, #22176, #22177, #22178, #22228, #22305, #22309, #22415, #22495, #22499, #22562, #22591, #22596, #22632, #22680, #22694).

2.17.8 — 23.04.2019¶

• Исправлены ошибки (#22223, #22224).

2.17.7 — 22.04.2019¶

• Улучшено распознавание Ирландии, Казахстана и Нидерландов.

2.17.6 — 17.04.2019¶

• Исправлена ошибка распознавания на краях кадра (#21957).

2.17.5 — 15.04.2019¶

• Улучшено распознавание Ирландии и Казахстана.
• Исправлена ошибка (#22054).

2.17.4 — 08.04.2019¶

• Добавлен SQL Server 2017.
• Улучшена работа с базой данных (только для SQL Server 2017) (#21948).
• Улучшено распознавание номеров.
• Исправлены ошибки модуля Pass24Online.
• Исправлены ошибки (#21740, #22085, #22013, #21922).

2.17.3 — 28.03.2019¶

• Исправлены ошибки с пропусками.

2.17.2 — 28.03.2019¶

• Улучшено распознавание Казахстана.

2.17.1 — 26.03.2019¶

• Обновлен файл trial лицензии.

2.17.0 — 25.03.2019¶

• Добавлены шаблоны номеров следующих стран: Грузия, Ирландия, Португалия (#21650, #21746, #17059).
• Улучшено распознавание следующих стран: Армения, Киргизия, Узбекистан (#21766, #21347, #21683).
• Добавлен в описании HTTP-сервера адрес localhost:45555 в качестве примера (#20914).
• Добавлен флаг о редактировании оператором номера в журнале распознавания (#21322).
• Добавлена пометка для удаленных списков (#21337).
• В плагине Camea добавлена возможность задать размер номера (#20882).
• Добавлен плагин «Экспорт для ЦАФАП» (#21101).
• Web-клиент: добавлена возможность кастомизации логотипа (#20988).
• Добавлена возможность запускать Автомаршал в свёрнутом виде (#21513).
• Окно ручной регистрации: добавлена возможность запретить регистрацию ТС, не имеющего определенного направления движения (#21550).
• Окно ручной регистрации: добавлена возможность отображать фотографии водителей в окне регистрации (#20467).
• Добавлена возможность включать/отключать триггеры (#20700).
• Добавлено окно «Парковка» (#21447)
• Обновлена логика проверки пропуска для списков Pass24.Online (#21034).
• Добавлена возможность прикреплять к отчету изображения ТС, в плагине «Рассылка отчетов» появилась возможность отправлять отчеты через фиксированные промежутки времени (#20678).

2.16.3 — 14.02.2019¶

• Изменен плагин «Внешняя база данных» (#20502).
• Добавлена возможность запускать программу в свернутом виде (#21513).

2.16.2 — 31.01.2019¶

• Улучшено распознавание номеров Киргизии.
• Исправлены ошибки.

2.16.1 — 31.01.2019¶

• Исправлены ошибки.

2.16.0 — 29.01.2019¶

• Добавлены шаблоны номеров следующих стран: Катар, Люксембург (#20331, #17060).
• Добавлены шаблоны номеров у следующих стран: Беларусь, Гонконг, Чехия (#21131, #21138, #20449).
• Улучшено распознавание Республики Киргизия (#20722)
• Добавлено удаление просроченных пропусков (#19302).
• Новый алгоритм предобработки видео (#20526).
• Переработано окно настроек предобработки видео (#11785).
• Добавлено отображение количество свободных парковочных мест на LED панели (#20468).
• Обновлена интеграция с Pass24.online (#19008).
• В триггерах добавлена возможность вносить распознанный регистрационный номер ТС в выбранный пользовательский список или удалять распознанный номер из выбранного списка (#20333).
• В «Журнал действий пользователя» записываются сообщения об изменениях настроек триггеров, создании или удалении триггера (#20647).
• В «Журнал действий пользователя» записываются сообщения о добавлении/удалении пользовательских списков, их изменении (название, перенос номера/водителя, удаление номера/водителя) (#20674).
• Исправлено поведение фильтра журнала распознавания — применение при закрытии, дополнительно добавлена кнопка «Применить» (#20435).
• Разработка программного модуля формирования сообщений для ЕАИС ФТС (#20453).
• В модуль Передний и задний номер добавлен режим с одним датчиком (#20909, #20857, #20981).
• Добавлена возможность прятать истекшие пропуска (#15083).
• В конфигураторе отчетов добавлена возможность добавлять поле длительность пребывания в минутах (#20817).
• При переполнении БД появляется информационное сообщение. (#19975).
• Web-клиент: Переведён интерфейс страницы редактирования списка на material design (#16387, #16731).
• Web-клиент: Проведена адаптация страницы редактирования списка под мобильные устройства (#17217).
• Web-клиент: Добавлена возможность скрытия кнопки «Пропуск» в гостевых пропусках (#20483).
• Web-клиент: Исправлены ошибки (#20987, #20223, #20223, #20970, #21046, #21125, #20483, #20487, #20849, #20850, #20851, #20852, #20876, #20879, #20964, #20855).
• Исправлены ошибки (#20711, #20711, #20480, #20830, #20982, #20868, #20500, #20732, #21063, #21063, #21096, #20435, #20868, #21045, #20543, #21007, #20750, #20681, #20838, #20763, #19860, #20486, #20729, #20728).
• Переработан плагин очистки БД (#19973).
• Списки, справочники, территории, водители, типы ТС по умолчанию сортируются по алфавиту (#20470).
• Поднят приоритет ручного распознавания над ручной проверкой (#20471).
• В управление списками добавлены столбцы: приоритета и редактирование шаблона пропуска (#20504,#20489).
• Убрана возможность добавлять записи в скрытие списки (#20950).
• Включить расширение границы номера и контрастирование (#20881).
• В License Manager после записи ключа в Redmine добавляется сообщение с номером ключа(#20915).
• Добавлено лицензирование программного модуля Автомаршал формирования сообщений для ЕАИС ФТС (#20834)
• Переработаны пресеты для VIRIS (#20151)
• Добавлен новый плагин Sefica ProBox с функционалом NX Witness (#20320)

2.15.1 — 19.11.2018¶

• Исправлены ошибки (#18201, #20589).

2.15 — 12.11.2018¶

• Добавлены шаблоны номеров следующих стран: Азербайджан, Испания, Франция (#17057, #17253, #17253)
• Окно управления списками перенесено из настроек в раздел «База данных» основного меню Автомаршал (#19842).
• Добавлены кнопки предыдущая/следующая запись и предыдущий/следующий проезд в окне редактирования записи (#13605).
• Добавлен столбец «Статус пропуска» в Журнал распознавания и в детали записи (#18526).
• В детали записи добавлены столбцы «Размер номера», «Размер кадра» и «Вероятность распознавания» (#14930).
• Список выполняемых триггерами действий разбит на группы (#19808).
• В окне поиска выпадающие списки отсортированы по алфавиту (#19885).
• Добавлена возможность сформировать быстрый отчет за выбранный временной период (#19495).
• Установлен лимит количества записей при формировании отчета, добавлены окно прогресса загрузки записей из базы данных и возможность отмены загрузки (#19878).
• Добавлен модуль формирования единой записи с передним и задним номерами ТС (#18201).
• Модуль «Тарификация»: добавлена возможность указания настроек тарифа для каждого из типов ТС (#16724).
• Модуль «Тарификация»: расширены возможности настройки гибкого посуточного тарифа (#19616, #19661).
• Добавлен модуль «Внешняя база данных» (#19719).
• В модуле Camea добавлено сохранение кадра при проезде ТС по индукционной петле (#19970).
• Добавлен модуль интеграции с парковочной системой VECTOR_AP (#20161).
• Добавлена интеграция с веб-сервисом «Дупло 2» (#19992).
• Добавлены горячие клавиши для вызова окон «Управление списками», «Редактирование списков», «Найти номер ТС» (#19807).
• Добавлены горячие клавиши для вызова окна ручного распознавания на определенном видеоканале (#19805).
• Web-клиент: добавлена система уведомлений, в том числе уведомление о несовпадении версий Автомаршал и web-клиента (#19234).
• Web-клиент: информация о роли пользователя добавлена в главное меню (#19234).
• Исправлены ошибки локализации (#19053).
• Исправлены ошибки (#20062, #20087, #20170, #19290, #19776, #19972, #20210, #20112, #20110, #19650, #20180, #20085).
• Исправлены ошибки (#19832, #19853, #20274, #19954, #20075, #20090, #20048, #19843, #19844, #19967, #19397, #20099).
• Исправлены ошибки (#20080, #20056, #20087, #20100, #20174, #19462, #20209, #20209, #20317).

2.14.1 — 07.09.2018¶

• Добавлены шаблоны номеров следующих стран: Кувейта, ОАЭ (#17763, #17058).
• Добавлена поддержка российского номера для мотоцикла (#19314).
• Добавлена возможность удаления несколько записей из журнала распознавания (#19404).
• Добавлена возможность записи изображения с выбранных камер после активации триггера (#18101).
• Добавлена возможность проверки наличия/отсутствия парковочных мест на Территории пользовательского списка (#19000).
• Добавлено контекстное меню в окне поиска, позволяющее производить операции над выбранной записью: редактировать, искать по журналу, вносить ТС в пользовательский список (#19519).
• Добавлена возможность отображения окна ручной проверки при обнаружении номера, не принадлежащего к пользовательским спискам (#13750).
• Добавлена возможность настройки срабатывания триггера по заданному расписанию с указанием времени и дня недели (#15445).
• Добавлена возможность проверять пропуск в списках в PASS24.Online (#19131).
• Добавлен фильтр по пользовательским спискам в модуле Рассылка отчетов (#19096).
• В приложении для записи ключей добавлена возможность печати на этикетку информации о лицензии (#19527).
• Добавлены дополнительные поля в шаблонизаторе (#18747).
• Добавлена возможность группового выделения с возможностью копирования, вставки и удаления текста в ячейках (#15517).
• Оптимизация журнала распознавания (#19598).
• Цвет ячеек, предназначенных только для чтения в пользовательских списках, изменен на серый (#19585).
• Web-клиент: Добавлена возможность изменять расположение элементов на странице журнала распознавания (#18163).
• Web-клиент: Добавлена возможность печати квитанции для выбранной записи в журнале распознавания на странице «Журнал» (#18350).
• Web-клиент: Добавлено отображение пользовательских отчетов на странице «Отчёты» (#18350).
• Web-клиент: Добавлено право для ролей на выписку отчётов (#18350).
• Web-клиент: На странице журнала распознавания добавлено отображение длительности пребывания ТС (#19168).
• Web-клиент: Добавлено право на просмотр списка серверов (#19169).
• Web-клиент: Добавлено право на просмотр видео (#19169).
• Web-клиент: Добавлена возможность настраивать содержание бокового меню в зависимости от прав роли (#19169).
• Web-клиент: Добавлен фильтр по пользовательскому списку (#19170).
• Web-клиент: Исправлен перевод дат в зависимоти от часового пояса (#19280)
• Web-клиент: Исправлено отображение распознанных вручную ТС на странице журнала распознавания (#19554).
• Исправлены ошибки локализации: (#19273), (#19299), (#19744).
• Исправлены ошибки: (#19585), (#19709), (#19726), (#19585), (#19617), (#19654), (#19601), (#19590), (#19776), (#19053), (#19788), (#19800), (#19765), (#19852).

2.13.2 — 20.08.2018¶

• Исправлена ошибка (#19530)

2.13.1 — 13.08.2018¶

• Добавлено возможность добавить номер ТС в список из окна Поиска (#19519)
• Исправлены ошибки перевода на английский язык.
• Исправлены ошибки (#19352,#19419, #19160, #19073, #19476, #19462, #17607, #19501, #19499, #19498, #19536, #19547, #19543, #19053)

2.13.0 — 01.08.2018¶

• Добавлен новый тип шаблонов номеров следующих стран: Россия (#19113).
• Добавлена возможность в отчетах выбирать кодировку номера ТС в кириллице или латинице (#18784).
• Добавлена возможность записывать в журнал действий пользователя информацию при срабатывании триггера (#15172).
• Добавлена маска ввода номера телефона для отправки SMS в триггерах (#18806).
• Добавлена статистика по размерам номеров/символов (#19073).
• Реализована возможность посылать SMS/e-mail сообщение при потере видеопотока с камеры (#17490).
• Добавлено условие действия триггера при отсутствии свободных парковочных мест (#17495).
• Перенесено руководство пользователя в установщик (#17525).
• Добавлена возможность отправки номера по протоколу Wiegand через адаптер Z2-Base (#19034).
• Реализована возможность подключения нескольких светодиодных экранов (#18755).
• Добавлена возможность идентифицировать авто с истекшим пропуском (#18035).
• Добавлено удаление изображений в плагине «Очистка базы данных» (#19185).
• Добавлена настройка времени очистки базы данных в плагине «Очистка базы данных» (#19248).
• Добавлен посуточный гибкий тариф в плагине «Тарификация» (#17607).
• Доработана настройка OEM1 (#18213).
• Доработана интеграция с Gate (#18503).
• Исправлены ошибки (#19039, #19238).
• (Оптимизация запроса загрузки данных) Выводить записи проездов авто после применения настроек окна поиска (#18157).
• Оптимизация запроса загрузки данных из базы в журнале распознавания (#18263).
• В менеджер лицензий добавлена возможность лицензирования AM-LED (#18743).
• Добавлено сохранение имен модулей в название лицензии для менеджера лицензии (#19028).
• Отредактированы пользовательские сообщения на английском языке (#18991).
• В АМ добавлено лицензирование программного модуля для подключения светодиодного экрана (#18742).
• Импорт из CSV. Добавить возможность импорта списка из веб-интерфейса контроллера NetAXS — 123 (#19175).

2.12.1 — 14.06.2018¶

• Добавлены шаблоны номеров следующих стран: Южная Корея (#17138).
• Добавлен модуль интеграции с LED-панелью ListenVision (#16716).
• Добавлена возможность вывести на LED-панель значения доп.полей модуля тарификации: к оплате, валюта, тип тарификатора. (#18071).
• Добавлено окно поиска водителя (#18268).
• Редактор записей в списках: добавлена возможность выбора значений из справочников (*бета-версия #18207).
• Редактор записей в списках: добавлена возможность объединять списки (#18269).
• Пользовательские списки: при создании пользовательского списка его цвет устанавливается случайным образом (#18609).
• Менеджер баз данных: добавлена возможность сменить пароль администратора (#18221).
• Обновлена интеграция с РПС (#18366).
• Добавлен модуль интеграции с Дом.Контроль (#18281).
• Добавлен модуль интеграции с PASS24.online (#18289).
• Web-клиент: Добавлена возможность импорта и экспорта пользовательских списков (#17454).
• Web-клиент: Расширен список поддерживаемых браузеров (#17729).
• Устранена утечка памяти в источнике FFmpeg (#17378).
• Добавлена функция формирования платежной квитанции за парковку (#15498, #18796).
• Исправлены ошибки.

2.11.10 — 14.05.2018¶

• Исправлены ошибки.

2.11.9 — 23.04.2018¶

• Исправлены ошибки.

2.11.8 — 20.04.2018¶

• Исправлены ошибки.

2.11.4 — 17.04.2018¶

• Исправлены ошибки.

2.11.3 — 17.04.2018¶

• Окно ручной регистрации ТС: добавлена возможность сравнивать фото водителя с оригиналом из базы данных (#17401).
• Исправлены ошибки.

2.

11.1 — 10.04.2018¶

• Редактор записей в списках: добавлено выделение цветом просроченных пропусков (#15793).
• Редактор записей в списках: добавлена возможность сохранять фотографии водителей и ТС (#17371).
• Территории: изменена логика разметки территорий и подсчета свободных мест на территориях, а также добавлен редактор выделенных мест парковки для пользовательских списков (#17375).
• Журнал распознавания: добавлен столбец территория (#17770).
• Журнал распознавания: добавлена возможность сортировать журнал по значениям дополнительных столбцов (#10377).
• Окно ручной регистрации ТС: добавлен раздел настроек «Ручная регистрация ТС» (#17614).
• Окно ручной регистрации ТС: добавлена возможность настройки «обязательное поле» для дополнительных полей и выпадающих списков (#17483, #17566).
• Окно ручной регистрации ТС: добавлена возможность включения/выключения автозаполнения для дополнительных полей, выпадающих списков справочников и водителей, также возможность выбора режима автозаполнения (#17531, #17618).
• Окно ручной регистрации ТС: изменен способ управления пользовательскими списками (#17677).
• Окно ручной регистрации ТС: добавлен вывод подсказки при вводе значений дополнительных полей (#17625).
• Обновлена схема БД до версии 13 (#17534).
• Добавлена возможность настраивать дополнительные поля в конфигураторе отчетов (#17376).
• Окно поиска: Сортировка в окне поиска применяется к отчету (#17697).
• Добавлена поддержка сторожевого таймера OEM1 WD461 (#12363).
• Web-клиент: Добавлено отображение срока пропуска на странице журнала (#16628).
• Web-клиент: Добавлена выгрузка отчётов (#15594).
• Web-клиент: Улучшен видеоплеер (#16728).
• Web-клиент: Страница видеонаблюдения адаптирована под мобильные устройства (#17218).
• Web-клиент: Привязка триггеров к видеоканалам перенесена в настройки (#17624).
• Улучшен интерфейс пользователя (#18136, #18138).
• Исправлены ошибки (#17779, #17779, #17735, #18131, #18160).

2.10.10 — 22.02.2018¶

• Улучшено распознавание номеров следующих стран: Кыргызстан (#17617).
• Исправлена ошибка с вставкой полей в списки их Excel (#17606).

2.10.9 — 16.02.2018¶

• Исправлены ошибки.

2.10.5 — 12.02.2018¶

• Добавлены шаблоны номеров следующих стран: Россия, Молдова (#17363, #17399).
• В раздел детальной информации о распознанном номере в главной форме добавлена возможность отображения и настройки полей из Журнала распознавания (#16934).
• Добавлена возможность указывать период действия пропуска относительно текущей даты с помощью шаблона пропуска (#16792).
• Окно редактирования списков: добавлена возможность одновременного редактирования группы выбранных пропусков (#15322).
• Окно редактирования списков и справочников: добавлена возможность одновременного удаления группы выбранных записей (#15516).
• Окно редактирования списков и справочников: добавлена возможность выбора списка во время добавления записей (#17403).
• Триггеры: в событие активации «Обнаружено транспортное средство» добавлены новые условия — проверка номера и типа ТС (#16684).
• Триггеры: в событии активации «Обнаружено транспортное средство» в условии «Длительность пребывания» увеличен диапазон выбираемых временных значений (#16899).
• Программа обслуживания БД: добавлено автоматическое резервное копирование перед обновлением базы данных (#16433).
• Программа обслуживания БД: добавлен индикатор процесса удаления данных из Журнала распознавания (#16842).
• Программа обслуживания БД: в провайдер БД SQL Server добавлен индикатор процесса резервного копирования и восстановления данных (#16842).
• Модуль «Экспорт данных на диск»: добавлена возможность выгрузки кода страны распознанного номера ТС в следующих форматах: ISO3166-1 alpha-2, ISO3166-1 alpha-3, ISO3166-1 numeric (#16586).
• Модуль «Экспорт данных на диск»: добавлена возможность задавать шаблон имени выгружаемых XML файлов (#17129).
• Модуль IDIS: в действие триггера «Отправить сообщение в IDIS» добавлена поддержка нового стандарта передачи данных системы IDIS (#17183).
• Web-клиент: добавлена пробная версия (#15889).
• Web-клиент: добавлено предупреждение об использовании cookie файлов (#17061).
• Web-клиент: добавлена возможность задавать время действия пропуска (#17352).
• Web-клиент: добавлена возможность указать максимальный срок действия гостевого пропуска при его создании Заявителем (#17033).
• Web-клиент: добавлена возможность настройки ограничений по каналам серверов для разных пользователей (#17084).
• Web-клиент: страница списков адаптирована под мобильные устройства (#17088).
• Web-клиент: страница журнала адаптирована под мобильные устройства (#17111).
• Web-клиент: страница гостевых пропусков адаптирована под мобильные устройства (#17159).
• Web-клиент: страница входа адаптирована под мобильные устройства (#17404).
• Исправлены ошибки.

2.9.7 — 15.01.2018¶

• Исправлены ошибки.

2.9.6 — 29.12.2017¶

• Улучшено распознавание номеров следующих стран: Казахстан, Кыргызстан.
• Исправлены ошибки.

2.9.5 — 22.12.2017¶

• В пользовательские списки и справочники добавлена горизонтальная полоса прокрутки (#17233).
• В условие срабатывания триггера «Проверка свободного количества мест» добавлен новый способ проверки свободного пространства с учетом размера парковочных мест (#17229).

2.9.3 — 21.12.2017¶

• Улучшена отрисовка номеров следующих стран: Великобритания, Германия (#16490, #16488).
• Добавлены новые типы номеров следующих стран: Болгария, Казахстан, Нидерланды (#16872, #16662, #16292).
• Улучшено распознавание номеров следующих стран: Болгария, Казахстан.
• Разработан механизм репликации данных средствами SQL Server (#16806).
• Добавлена возможность задать емкость парковки и ограничения на число парковочных мест для разных пользователей (#14303).
• Добавлена возможность создавать и настраивать роли пользователей (#16499).
• В окне редактирования записи добавлена информация о длительности пребывания ТС на территории (#16793).
• В окне ручной проверки добавлена возможность выбора типа ТС, водителя и направления движения (#16926).
• В пользовательские списки добавлен справочник «Список водителей» (#16341).
• Добавлена возможность импорта/экспорта списков с пропусками в XML в (#16630).
• В отчет «Посещения» добавлена информация о количестве пассажиров на территории (#16342).
• Добавлена возможность очистки базы данных (#16722, #16929).
• Реализовано приложение для отображения рекламы на основе распознанного номера (#15238).
• Добавлен модуль интеграции с Clean-Control (#16588).
• Web-клиент: Добавлена настройка внешнего вида страницы журнала (#17012).
• Web-клиент: Добавлено сохранение настроек внешнего вида интерфейса пользователя (#16897).
• Web-клиент: В журнале добавлен вывод дополнительной информации о ТС для выбранной записи (#16927).
• Web-клиент: Добавлена фильтрация по каналам (#16744).
• Web-клиент: При добавлении номера в список доступа можно указать тип ТС (#16949).
• Web-клиент: Добавлена возможность указать время начала и конца действия пропуска (#16794).
• Web-клиент: Добавлена возможность добавлять свои поля в гостевые списки (#16712).
• Web-клиент: Добавлено отключение требования авторизации при использовании API (#17025, #16935).
• Web-клиент: Добавлено оповещение пользователя о том, что фильтр поиска применён (#16711).
• Web-клиент: Обновлён дизайн страницы гостевых пропусков (#16894).
• Исправлены ошибки.

2.8.3 — 10.11.2017¶

• Добавлен встроенный справочник «Типы ТС» (#16663).
• Улучшена отрисовка номеров следующих стран: Таджикистан, Бельгия, Чехия, Турция, Италия, Польша (#16489, #16417, #16418, #16420, #16421, #16422).
• В период действия пропуска можно задать время (#16345)
• Web-клиент: Обновлён визуальный стиль журнала (#16639, #16307).
• Web-клиент: Изменён формат отображения журнала для пользователя «Заявитель». Пользователю этого типа отображаются только ТС, номера которых он добавил в гостевые пропуска (#16356).
• Добавлен поиск по всем полям «Журнала распознавания» (#16623).
• Более точный вывод границ изображения номера ТС (#16612, #16612).
• Добавлена возможность удаления записи в «Журнале распознавания» под учетной записью администратора (#16348).
• Добавлена возможность вызвать окно редактирования записи и связанной записи из контекстного меню «Журнала распознавания» (#16404).
• При ручном распознавании добавлена возможность указать дату и время (#16487).
• Добавлена возможность отображения окна тревоги в случае превышения числа разрешенных проездов. (#16266).
• Модуль «Измерение скорости»: Добавлена поддержка нескольких радаров (#16372).
• Модуль «Экспорт данных на диск»: в настройках XML добавлен атрибут «Имя направления» (#16622).
• Модуль «Тарификация»: добавлена возможность сопоставления тарифа c пользовательским списком (#16150).
• Модуль «Тарификация»: добавлена возможность задать валюту расчетов. В «Журнал распознавания» добавлены столбцы «Валюта» и «Тарификатор» (#14686).
• Исправлены ошибки.

2.7.3 — 16.10.2017¶

• Добавлена возможность в окне ручной проверки номера указать список с его доп. полями и пропуск (#15697).
• Добавлена поддержка устройств ввода-вывода ICP CON (Ethernet) серии ET и PET, работающих по протоколу Modbus Slave (#16135).
• Добавлена возможность управления триггерами в Web-клиенте (#15497).
• Добавлена поддержка распознавания номеров новых стран: Финляндия (FI) (#16031).
• Улучшена отрисовка номеров следующих стран: Литва, Эстония, Молдова, Болгария, Румыния (#16078, #16080, #16081, #16287, #16295, #16297).
• Изменен формат отображения длительности пребывания в Журнале Распознавания (#14720).
• Доработана интеграция с видеорегистраторами IDIS, добавлена возможность отправки информации в настраиваемом (произвольном) формате с помощью триггеров (#14799).
• Редактирование информации о транспортном средстве в списках доступа и Журнале распознавания теперь не приводит к изменению информацию в Журнале * распознавания о предыдущих проездах этого транспортного средства (#15564).
• Для пользовательских списков реализован выбор полей из фиксированного набора, что позволяет исключить дублирование полей в Журнале распознавания (#13922).
• В журнал распознавания добавлены столбцы Флаг страны и Код страны (#15689, #16123, #16235).
• В Web-клиенте реализовано предупреждение при истекающем сроке действия пропуска (#16060).
• В журнале распознавания и в окне поиска добавлена возможность фильтрации записей по направлению (въезд/выезд) (#15695).
• В видеоисточнике FFmpeg добавлена настройка выбора предпочтительного протокола (TCP/UDP) для получения данных с видеокамеры (#16247).
• Добавлено предупреждение об использовании неподдерживаемого браузера в Web-клиенте (#16061).
• Реализована возможность просмотра и редактирования доп. полей при ручном распознавании (#15022, #16149).
• Добавлена проверка прав пользователя на выполнение триггеров (#16220).
• В Web-клиенте реализован механизм разграничения прав на действия пользователей (#15615).
• Модуль экспорт данных на диск. Добавлена возможность записывать значения доп. полей в файлы xml (#16049).
• Модуль экспорт данных на диск. Добавлена возможность впечатывания данных (дата, время, номер автомобиля и др.) в экспортируемые изображения (#15782, #16205, #16207).
• При первом запуске ПО после обновления при нажатии на кнопку «Обновить базу данных» выводится предупреждение с текстом о необходимости создания резервной копии базы данных (#16122).
• Исправлены ошибки.

2.6.0 — 01.09.2017¶

• Добавлена возможность отправки SMS и e-mail по срабатыванию триггера (#15343).
• Добавлена поддержка устройства ввода/вывода ICPCON ET-7052 (#16033).
• Добавлен модуль «Измерение скорости» (#16017).
• Добавлена возможность просмотра видео в Web-клиенте через Интернет (#15993).
• Добавлен гостевые списки в Web-клиенте (#15974).
• Добавлены шаблоны номеров: Великобритания, Израиль, Италия (#15818, #15775, #15734).
• Улучшена отрисовка шаблонов номеров: Латвия, Израиль (#16079, #16024).
• Добавлена возможность указать шаблон номера при ручном распознавании и редактировании записи в журнале (#15512).
• Модуль «Экспорт данных на диск»: добавлена возможность настройки имени файла выгружаемых изображений (#14421).
• Исправлена ошибка в поддержке устройства ввода/вывода Advantech 4750 (#16065).
• Web-клиент переведен на английский язык (#15372).
• Улучшен интерфейс настройки видеоканалов (#15897).
• Удалена вкладка «Статус ТС». Ее функционал реализован системой триггеров (#15837).
• Добавлена возможность отключения отображения заблокированных решений в видеоокне (#15613).
• Изменены параметры по умолчанию алгоритмов распознавания (#15550).
• Исправлены ошибки.

2.5.6 — 18.

08.2017¶

• Реализована возможность подключения нескольких устройств ввода/вывода (#14247).
• Добавлена возможность присваивать направлению движения название (#14296).
• В окне ручного распознавания изменены варианты выбора направления (#15805).
• В модуле «Экспорт данных на диск» добавлена возможность настраивать формат и содержимое xml и csv файлов, которые будут сохраняться на диск для интеграции с ПО Clean-control, RealSoft и другими системами (#15342).
• Добавлена возможность сохранения XML-файлов в зависимости от направления проезда ТС: ‘въезд и выезд’, ‘только въезд’, ‘только выезд’ (#15821).
• При редактировании связей въезд-выезд у связанной записи меняется направление на противоположное автоматически (#15873).
• Добавлен новый сервис отправки SMS-сообщений sms.traffic.ru в модуль sms-уведомлений (#15448).
• Улучшена отрисовка номеров следующих стран: Беларусь, Донецкая Народная Республика, Узбекистан, Абхазия, Армения и Монголия (#15829, #15746, #15723, #15688).
• Добавлена поддержка распознавания следующих типов номеров республики Беларусь (BY, BLR) (дипломат. и образца до 2000г.) (#15652).
• В строку меню главного окна добавлен раздел «Отчеты» (#15495).
• На видеоканалах добавлено отображение кнопок выполнения триггеров (#14852).
• В отчеты добавлена информация из дополнительные полей и полей из пользовательских списков (#14081).

Известные проблемы:
* При обновлении ПО Автомаршал с предыдущих версий настройки триггеров сбрасываются в значения по умолчанию. Перед обновление необходимо сохранить скриншоты «старых» настроек и перенастроить ПО.

2.5.5-2 — 14.08.2017¶

• Исправлена ошибка в взаимодействии с контроллерами ICP-CON (#15927).

2.5.5 — 31.07.2017¶

• Добавлена фильтрация по спискам в модуле «SMS-уведомления» (#15184).
• Добавлена фильтрация по спискам в модуле «Telegram-уведомления» (#15170).
• Выпущена новая версия Web-клиента с возможностью просмотра видео, фильтрации журнала и управления пользовательскими списками (#13114, #13086, #12773).
• Добавлена возможность редактирования связи въезд-выезд траспортного средства (#13912).
• Добавлена возможность задавать вручную направление движения в окне редактирования номера и при ручном распознавании (#15139).
• Добавлено отображение процесса сохранения изображений на диск из окна поиска (#15261).
• Улучшена отрисовка шаблонов номеров: Киргизии (#15501).

2.5.4 — 29.06.2017¶

• Добавлен модуль интеграции с СКУД «Сфинкс» (#13029).
• В модуль «Управление устройствами» добавлена поддержка Uniping v3 (#15082).
• Добавлена возможность передачи сообщений в мессенджер Telegram (#15196).
• Улучшена отрисовка шаблонов номеров: Казахстан, Белоруссия, Укранина, Бельгия, Нидерланды (#15305).
• Реализована возможность настройки колонтитулов в отчете и добавление произвольных текстовых меток (заголовков) (#15317).
• Добавлена возможность настройки произвольной формы зоны распознавания по 8-ми точкам (#15454).
• Обновлена интеграция с Milestone Corporate XProtect 2017 R2 (#15401).
• Добавлена beta-версия детектора ТС (#13099).

2.5.3 — 31.05.2017¶

• Добавлена возможность указать непрямоугольную область распознавания (#15000).
• Исправлена критическая ошибка при попытке выбрать OEM1 в модуле управление устройствами (#15026).
• Исправлена ошибка подключения к устройству входов-выходов после перезапуска плагина (#12678).
• Улучшена работа с натурлистами (#15130).
• Добавлены новые условия для события активации «Обнаружено траспортное средство» в модуле «Управление устройствами» (#14882, #14883).
• Добавлен фильтр по датам в журнал распознавания на главной форме приложения (#14907).
• Убрано отображение дублирующихся камер (истории их редактирования) в фильтрах окна поиска, статистики и журнала распознавания (#13316).
• Добавлены шаблоны новых номеров Казахстан (#14816).
• Добавлены шаблоны новых номеров Кыргызской республики (#14811).
• Добавлены шаблоны номеров Донецкой Народной Республики (#14571).
• Реализован простой редактор отчетов с возможностью добавления и удаления (#15090).
• Реализована опция, при включении которой не будет учитываться регион при сверке распознанного номера со списками (#12312).
• Добавлена возможность отправки SMS если авто въезжает/выезжает в определенное время (#14922).
• Исправлены ошибки.

Известные проблемы:
* При обновлении ПО Автомаршал с предыдущих версий настройки алгоритмов сбрасываются в значения по умолчанию. Перед обновление необходимо сохранить скриншоты «старых» настроек.

2.5.2 — 26.04.2017¶

• Исправлены ошибки.

2.5.1 — 24.04.2017¶

• Поддержка VLC-плеер версии 2.2.4 (#14533).
• Добавлена возможность просмотра увеличенного фото ТС в отдельном окне (#9804).
• Улучшена интеграции с Milestone XProtect (#14668).
• Реализована интеграция с системой NxWitness (#14557).
• Добавлен модуль для передачи номера по протоколу RS232/485 (#14460).
• В модуль «Отправка SMS» добавлен новый провайдер (#14511).
• Добавлен обработчик для возврата номера по HTTP запросу и выполнения триггеров по HTTP запросу (#14632).
• Добавлен модуль «Тарификатор» (настройка тарификации и формирование отчета) (#13081, #12987, #13016).
• Добавлена поддержка MOXA ioLogik E2210 и E2214 (#14932).
• В окне статистики по дням подсвечивать выходные (#14721).
• Исправлены ошибки.

2.5.0 — 20.02.2017¶

• Реализована технология FileStream для СУБД SQL Server (#13794, #14334, #14393, #14476).
• Реализован редактор пропусков (#14068, #14358).
• Реализовано расписание доступа (#13230, #13464, #14465).
• Добавлен функционал сохранения и просмотра изображений с обзорных камер (#11322, #11966, #14265, #14388, #14447, #14457).
• Добавлен новый источник видео FFmpeg (#11769).
• Добавлена интеграция с системой Camea (#14241).
• Добавлена интеграция с видеорегистратором Idis (#13996).
• Добавлена интеграция с устройством ввода-вывода Moxa ioLogik E2212 (#14200).
• Добавлена интеграция с устройством ввода-вывода VP241 (#12362, #13833).
• Добавлено предупреждающе окно при полном заполнении БД(#14311).
• Изменен редактор пользовательских списков (#12297, #12493, #14067, #14332, #14356).
• Модуль «СКУД Gate»: реализована поддержка протокола третьей версии для системы СКУД Gate (#14211).
• Модуль «Управление устройствами»: в условие «Обнаружено ТС» добавлена проверка на пользовательские списки (#13796).
• Модули «Автомойка» и «Рилл-Софт»: реализована выгрузка данных в кириллицу (#13993).
• Ярлык утилиты Обслуживание БД Автомаршал помещается на рабочий стол (#14225).
• Исправлены ошибки (#13842, #14003, #14366, #14386).

2.4.5 — 16.11.2016¶

• Добавлен выбор СУБД SQL при установке ПО (#13515).
• Добавлена технология хранения изображений FileStream в СУБД SQL Express, позволяющая обойти ограничение БД по размеру (#13357, #13415, #13514).
• Добавлены шаблоны номеров Нидерланды (#13596).
• Улучшено распознавание номеров ТС на однородном фоне (#13537).
• Обновлены ссылки для скачивания VLC плеера (#13026).
• В окне Редактирование записи реализовано отображение детальной информации по камере (#13544).
• Исправлены ошибки.

2.4.4 — 20.10.2016¶

• Исправлены ошибки (#13553, #13573, #13575, #13576).

2.4.3 — 18.10.2016¶

• Добавлен мастер настройки подключения К IP-камере (#11770).
• Реализована интеграция с системой Итриум (http://www.itrium.ru) (#13144).
• Реализована интеграция с Milestone XProteсt (https://www.milestonesys.com) (#12172).
• Добавлен модуль «Рилл-Софт» (#13313).
• Добавлен отчет «Посещения» (#12908).
• Добавлен шаблон номера для сельскохозяйственной техники (#13329).
• Добавлены шаблоны номеров Таджикистан (#13163).
• Добавлен раздел «Направления перемещения ТС» (#12948).
• Добавлено предупреждение об обновленной схеме БД (#12920).
• Добавлен выбор формата времени: время ПК/UTC (#13278).
• Добавлена проверка доступности SMTP-сервера (#12986).
• Улучшен источник видео ПО Линия (#13387).
• Улучшен web-клиент (#13342).
• Улучшено отображение статистики распознавания номеров (#13276, #13318).
• Статистика: добавлены фильтры по серверам и каналам (#12966).
• Реализован вывод статистики по номеру из контекстного меню журнала распознавания (#12859).
• Модуль «Экспорт данных на диск»: добавлена выгрузка данных в файл формата xml (#13088).
• Сделан запрет на ввод одинаковых номеров в пользовательские списки (#13255 ,#13274).
• Исправлены ошибки.

2.4.2 — 06.10.2016¶

• Увеличено время блокировки распознанного номера (#13123).
• Добавлены шаблоны номеров Узбекистан (#13126).
• Добавлены шаблоны номеров Киргизия (#13131).
• Добавлен видеоисточник для подключения к серверу Milestone XProteсt (https://www. milestonesys.com) (#13097).
• Модуль «Экспорт данных на диск»: исправлена конвертация имени файла в кириллицу (#13093).
• Модуль «Экспорт данных на диск»: выгрузка данных форматах xml или xls (#13088).
• Исправлены ошибки.

2.4.1 — 03.08.2016¶

• Добавлена возможность регистрации времени нахождения ТС на территории.
• Исправлены ошибки.

2.4.0 — 04.07.2016¶

• Добавлен модуль «Отчеты» (#7816, #11601, #12222).
• Добавлен Журнал действий пользователя (#12026).
• Добавлен вывод распознанного номера в отдельное окно (#12050).
• Добавлена опция «Не учитывать номер, если ТС не перемещается» (#11573).
• Добавлена индикация заполнения БД в статусной строке (#12335).
• Добавлены фильтры (по видеоканалу и по спискам) в окне Поиска (#12261).
• Реализован экспорт изображений из БД (#12038).
• Реализован вывод количества записей в окне Пользовательские списки (#12266).
• Реализована миграция из ПО версии 1. х в СУБД MS SQL Compact 2.0 (#12333).
• Реализовано добавление в пользовательские списки из контекстного меню в журнале распознавания (#11921).
• Модуль «Экспорт данных на диск»: добавлена возможность выбора кодировки для передаваемых номеров (#12219).
• Изменена структура главного меню (#12327).
• Изменены пользовательские списки (#11949, #12389).
• Улучшен импорт/экспорт пользовательских списков (#12189, #12346).
• Улучшено распознавание номеров, которые занесены в пользовательские списки (#10719).
• Улучшено отображение статистики распознавания номеров (#11970, #12351, #12594).
• Улучшены алгоритмы распознавания (#12361).
• Исправлена работа опции «Автоматически запускать при старте Windows» (#12388).
• Добавлен тестовый ролик при первом запуске ПО (#11707).
• Исправлены ошибки.

2.3.1 — 23.05.2016¶

• Сделана 64-разрядная версия ПО (#11375).
• Модуль «Управление устройствами»: улучшена стабильность работы с контроллером ICP DAS UCB-2060 (#12359).
• Повышена стабильность работы с IP-камерами.
• Исправлены ошибки экспорта в отчетах (#12180).
• Исправлены ошибки в модуле СКУД Gate (#12226, #12275).
• Исправлены ошибки.

2.3.0 — 19.04.2016¶

• Добавлен механизм аутентификации пользователей (#11592).
• Инсталлятор подписан сертификатом производителя ПО (#11046).
• Добавлена поддержка СУБД MS SQL Compact (#11759).
• Добавлена интеграция с RPS (http://r-p-s.ru) (#11370).
• Добавлена интеграция с AutoGard (http://www.autogard.cz) (#11566).
• Добавлена опция «Открыть папку» (#11589).
• Добавлена проверка на наличие обновлений Windows при установке ПО (#12036).
• Добавлено распознавание новых трехзначных регионов номеров РФ: 113, 124, 126, 134, 136, 142, 196 (#11796).
• Добавлено распознавание нового типа номера: Греция, Армения, Латвия.
• Добавлен индикатор пропущенных кадров (#11890).
• Модуль «Управление устройствами»: реализовано переподключение к контроллеру в случае потери сигнала (#11231).
• Модуль «Управление устройствами»: реализовано событие активации триггера по заданному направлению движения (#10675).
• Улучшена стабильность видеоисточника VLC.
• Улучшена форма настройки области распознавания и размеров номера (#10788).
• Исправлены ошибки.

2.2.0 — 19.02.2016¶

• Добавлено распознавание номеров 000aa00, 00000aa (Казахстан)(#11173).
• Улучшена интеграция с ПО «Линия».
• Добавлен встроенный http-сервер для интеграции со сторонним ПО.
• Добавлен возможность сохранения/восстановления конфигурации ПО.
• Добавлен редактор дополнительных полей.
• Добавлена дополнительная информация в окно «О программе…».
• Добавлено отображение статистики по распознанным номерам.
• Сделано контекстное меню в Журнале распознавания.
• Добавлено распознавание номеров 000aa00, 00000aa (Казахстан)(#11173).

2.1.1 — 25.01.2016¶

• Доработан модуль ‘Экспорт HTTP’.
• Улучшена кнопка автообновления журнала ТС.
• Исправлены ошибки в интеграции с Revisor VMS.

2.1.0 — 30.12.2015¶

• Добавлена интеграция с сервером Revisor VMS.
• Добавлена модуль ‘Экспорт HTTP’.
• Добавлено распознавание номеров 000aa00, 00000aa (Казахстан)(#11173).
• Исправлены ошибки.

2.0.10 — 27.11.2015¶

• Исправлены ошибки.

2.0.9 — 17.11.2015¶

• Вывод крупного изображения номера при настройке его размеров (#11057)
• Возможность приостановки основного процесса распознавания во время настройки (#11052)
• Плагин «СКУД Gate»: исправлена ошибка с повторной передачей номера в СКУД (#11077).
• Обновлена лицензия пробной версии (2 видеоканала распознавания, 1 видеоканал видеонаблюдения).
• Исправлены ошибки.

2.0.8 — 02.11.2015¶

• Добавлено распознавание номеров стран: Польша, Бельгия, Германия.
• Исправлены ошибки.

2.0.7 — 26.10.2015¶

• Возможность указать прокси-сервер при активации пробной версии.

2.0.6 — 22.10.2015¶

• Активация по интернету пробной версии.
• Обновлен инсталлятор драйвера Guardant.
• Исправлены ошибки.

2.0.5 — 16.10.2015¶

• Добавлен функционал сохранения изображений в различных форматах.

2.0.4 — 12.10.2015¶

• Исправлены ошибки.

2.0.2 — 23.09.2015¶

• Изменены настройки по умолчанию параметров алгоритмов распознавания.

2.0.1 — 16.09.2015¶

• Первый релиз 2.0.

1.56.1 — 23.09.2015¶

• Изменены настройки по умолчанию параметров алгоритмов распознавания.
• Плагин «Модуль парковки»: добавлен вывод количества въехавших автомобилей.
• Плагин «Управление устройствами»: реализовать возможность выбора условия сработки триггера по заданному направлению движения ТС.
• Удалены не используемые шаблоны номеров РФ (#10690).
• Исправлены ошибки в формировании отчета (#10689).

1.55.4 — 18.09.2015¶

• Плагин «Электронная почта»: добавлены настройки повторной передачи письма (#10654).
• Исправлена ошибка с неверных определением координат номера при нахождении на изображении нескольких номеров (#10631).

1.55.3 — 10.09.2015¶

• Исправлены ошибка с fps при получении видеопотока с ПО «Линия».
• Плагин «Электронная почта»: выгрузка в отчет даты и времени сделана в разные ячейки.

1.55.2 — 09.09.2015¶

• Удалены не используемые шаблоны номеров РФ (#10690).

1.55.0 — 07.09.2015¶

• Размеры номера и области обработки указывать в % от размера кадра (#10536).
• Добавлено сохранение текущего кадра в окне настроек размеров номера (#10577).
• Исправлена ошибка с сохранением настроек буфера кадров в окне настроек размеров номера (#10550).
• Сохранение в лог измененных настроек приложения.

1.54.1 — 03.09.2015¶

• Исправлена ошибка с потерей окна отчета или поиска с включенной опцией «Поверх всех программ» (#10562).
• Исправлена ошибка переподключением к СУБД Firebird после потери соединения (#10503).

1.54.0 — 01.09.2015¶

• Исправлена ошибка в плагине «Отчет по почте».
• На видео отображаются заблокированные решения (#10517).
• Распознавание номера при настройке его размеров (#10503).

1.53.2 — 25.08.2015¶

• Исправлена ошибка с вопроизведением звука.
• Исправлены ошибки в настройке размера номера.

1.53.1 — 20.08.2015¶

• Добавлена возможность отключения контекстного меню на форме видео.
• Добавлена разметка для показа видео с трех камер.
• Добавлена запись видео с использованием сжатия.
• Добавлены тултипы (всплывающие подсказки).
• Улучшена работа плагина «SMS».
• Улучшена работа плагина «Электронная почта».
• Исправлена ошибка с показом окна ввода пароля.
• Исправлены мелкие ошибки.

1.53.0 — 09.08.2015¶

• Добавлена возможность отключения настройки Zoom и Focus.
• Добавлено распознавание региона 186 (российские номера).
• Исправлена критическая ошибка при работе с БД.
• Исправлены мелкие ошибки.

1.52.0 — 07.07.2015¶

• Плагин «Управление устройствами»: добавлена поддержка контролера ICP DAS UDB-2060 (http://icp-das.ru/catalog/remote_i_o/usb2000/65789.html).
• Плагин «Управление устройствами»: добавлена поддержка контролера УИМ-4.
• Добавлен плагин «СКУД Gate».
• Исправлена ошибка отображения шаблонов номеров в настройках (#10131).
• Исправлены мелкие ошибки.

1.51.6 — 15.07.2015¶

• Устранены взаимные блокировки при записи в БД (#10217).

1.51.5 — 11.06.2015¶

• Исправлена ошибка создания БД при первом запуске.

1.

51.3 — 05.06.2015¶

• Изменено место создание файла БД по умолчанию (C:\ProgramData\Mallenom\Automarshal\Database\AUTOMARSHAL.FDB).

1.51.1 — 02.06.2015¶

• Улучшена настройка области распознавания.
• Улучшена настройка параметров распознавания.
• Добавлен алгоритм быстрой локализации (#9829).
• Исправлены ошибки в интерфейсе пользователя при запуске в MS Windows 8.
• Исправлены мелкие ошибки.
• Добавлен шаблон отображения номера для прицепов (ru).

1.50.3 — 14.05.1015¶

• Добавлен видеоисточник, использующий плеер VLC.
• Плагин «Управление устройствами»: добавлена поддержка модуля ввода-вывода ICP CON ET-7044/7060.

1.50.0 — 08.05.1015¶

• Улучшен алгоритм определения движения (#9414).
• Исправлены ошибка в интерфейсе настройки размеров номера (#9599, #9600).
• Возможность группировки каналов.
• Блокировка по идентичности номера сделана с учетом группы.
• Улучшен интерфейс настройки алгоритмов.
• Улучшено распознавание номеров Киргизия.

1.49.0 — 26.03.2015¶

• Улучшены настройки размеров области распознавания и номера.
• Убрана настройка принятия решения по нескольким каналам.
• Добавлена модель для номеров Киргизии.
• Добавлен новый шаблон номера для Украины.
• Исправлена ошибка в выборе кадра с ТС с распознанным номером.
• Исправлены ошибки в алгоритме принятия решения по движению.
• Исправлена ошибка инициализации каналов только для просмотра.
• Исправлены мелкие ошибки в интерфейсе пользователя.

1.48.2 — 18.02.2015¶

• Оптимизировано использование оперативной памяти.

1.48.1 — 17.02.2015¶

• Добавлен вывод графика определения движения.
• Изменен формат шаблонов номеров.
• Исправлены ошибки в работе алгоритмов.

1.47.4 — 10.02.2015¶

• Улучшен алгоритм определения движения ТС.

1.47.2 — 02.02.2015¶

• Повышена стабильность работы с БД Firebird.
• Улучшено распознавание украинских, казахстанских и белорусских номеров.

1.47.1 — 15.01.2015¶

• Исправлена ошибка обновления Журнала в Демоверсии.

1.47.0 — 15.01.2015¶

• Исправлена ошибка с обновление данных их БД Пользователя после редактирования в Журнале (#8900).
• Исправлена ошибка с установкой области распознавания номера на кадре (#8279, #7850).
• Исправлена ошибка в алгоритме предобработки изображения (#8876).
• Исправлена ошибка вывода времени в Клиенте (#8015).
• Сделана конфигурация «Демоверсия» (#8197).
• Плагин «Управление устройствами»: улучшена стабильность работы.
• Оптимизированы алгоритмы распознавания.

1.46.13 — 22.12.2014¶

• Оптимизировано использование оперативной памяти (#8840).

1.46.10 — 12.12.2014¶

• Исправлена ошибка с сохранением настройки предобработки видео на вкладке «Предобработка видео (улучшение)»

1.

46.7 — 05.12.2014¶

• Обновлен список поддерживаемых камер.

1.46.7 — 05.12.2014¶

• Улучшено получение видеопотока по RTSP+H.264.

1.46.6 — 03.12.2014¶

• Исправлена ошибка с сохранением настроек видеозахвата (#8736).
• Исправлена ошибка с отображением символа «С» (#8737).

1.46.5 — 20.11.2014¶

• Исправлена ошибка с отсутствием изображения ТС на диске и в БД (#8686).
• Улучшены алгоритмы распознавания номера.

1.46.4 — 20.11.2014¶

• Исправлена ошибка с отсутствием изображения ТС на диске и в БД (#8686).

1.46.3 — 18.11.2014¶

• Изменен текст в настройках алгоритмов.

1.46.2 — 17.11.2014¶

• Исправлена ошибка в выборе лучшего варианта распознавания номера (#8659).

1.46.1 — 14.11.2014¶

• Улучшено окно «Ручное распознавание».
• Исправлена ошибка в алгоритме обнаружения движения (#8649). Движения обнаруживалось без учета заданной области.

1.45.9 — 12.11.2014¶

• Улучшены алгоритмы распознавания номера (#8620).
• Вывод рамки номера на изображение.

1.45.8 — 31.10.2014¶

• Оптимизировано использование оперативной памяти (#8582).
• Исправлена ошибка в алгоритме распознавания (#8574).

1.45.6 — 29.10.2014¶

• Исправлена ошибка блокировки номера по движению (#8571).
• Исправлена ошибка сохранения параметра «Принимать решение после прекращения движения по истечении xx секунд…» (#8564).

1.45.5 — 16.10.2014¶

• В виджет управления объективом добавлена камера MDC.
• Исправлены ошибки.

1.45.4 — 16.10.2014¶

• Обновлен отчет в плагине «Парковка».
• Исправлены ошибки в плагина «Парковка».
• Обновлена структура БД плагина «Парковка».

1.45.2 — 13.10.2014¶

• Изменен формат отображения данных в журнале, в отчете и в окне поиска для плагина «Парковка».
• Добавлен посуточно-интервальный тарификатор и специализированный тарификатор в плагин «Парковка».
• Добавлен автоматический регистратор ТС с пополнением баланса на сумму прайса за еденицу времени в плагин «Парковка».
• В плагин «XmlRealSoft» введена возможность включения ‘старого’ формата (Без поля ‘id’).
• Добавлен виджет по управлению механическим объективом на некотрых моделях IP-камер.
• Исправлены ошибки.

1.44.1 — 06.10.2014¶

• Обновлен плагин «Парковка».
• Обновлены иконки.

1.44.0 — 02.10.2014¶

• Добавлен плагин «Парковка».

1.43.0 — 26.09.2014¶

• Расширен функционал плагина «XmlRealSoft».
• Оптимизировано использование оперативной памяти.

1.42.1 — 05.09.2014¶

• Добавлен плагин «XmlRealSoft» для интеграции с ИП:Автомойка (http://www.real-soft.ru/cgi-bin/h.pl?ipavto3).

1.42.0 — 01.09.2014¶

• Добавлен плагин «Измерение скорости».

1.45.0 — 13.10.2014¶

• Добавлена виджет по управлению механическим объективом на некотрых моделях IP-камер.
• Добавлен посуточно-интервальный тарификатор и специализированный тарификатор в плагин «Парковка».
• Добавлен автоматический регистратор ТС с пополнением баланса на сумму прайса за еденицу времени в плагин «Парковка».
• Исправлены ошибки.

1.44.1 — 06.10.2014¶

• Обновлен плагин «Парковка».
• Обновлены иконки.

1.44.0 — 02.10.2014¶

• Добавлен плагин «Парковка».

1.43.0 — 26.09.2014¶

• Расширен функционал плагина «XmlRealSoft».
• Оптимизировано использование оперативной памяти.

1.42.1 — 05.09.2014¶

• Добавлен плагин «XmlRealSoft» для интеграции с ИП:Автомойка (http://www.real-soft.ru/cgi-bin/h.pl?ipavto3).

1.42.0 — 01.09.2014¶

• Добавлен плагин «Измерение скорости».

1.

41.4 — 29.08.2014¶

• Плагин «Управление устройствами»: изменен механизм активации триггеров.

1.41.3 — 27.08.2014¶

• Плагин «Текстовый файл»: реализована возможность сохранять в файл id записи.
• Плагин «Управление устройствами»: добавлено принудительное выполнение триггеров.

1.41.2 — 18.08.2014¶

• Исправлена ошибка с ротацией логов.
• Исправлена ошибка с отображением цветного видео.
• Сделан более подробный вывод в протокол работы об используемой памяти.

1.41.1 — 13.08.2014¶

• Переработан плагин «Сумма задолженности».
• Улучшен вывод отладочной информации в плагине «Управление устройствами».
• Пункт «Лог» переименован в «Протокол работы».
• Добавлен импорт/экспорт таблиц пользователя.
• Исправлены ошибки с сворачиванием главной формы.
• Исправлены ошибки.

1.40.4 — 04.08.2014¶

• Исправлена ошибка с сохранением нераспознаных номеров в плагине «Текстовый файл»
• Убрана поддержка аппартных ключей защиты Hardlock.

1.40.3 — 31.07.2014¶

• Исправлена ошибка с хранением изображений траснпортных средств на диске.
• Исправлена ошибка с сохранением статуса в плагине «Управление устройствами».

1.40.2 — 21.07.2014¶

• Исправлена ошибка работы алгоритма установки размеров номера.

1.40.1 — 08.07.2014¶

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

1.34.5 — 02.06.2014¶

• Исправлена ошибка с распознавание номеров разных стран.
• Добавлено сообщение о необходимости перезапуска программы при вкл/выкл моделей номеров.

Примечение: при установке поверх предыдущей версии необходимо в файле automarshal.alg.cfg удалить строку «».

1.34.4 — 20.05.2014¶

• Исправлены ошибки.

1.34.3 — 15.05.2014¶

• Добавлен UIMPlugin (управление внешними устройствами).

1.34.2 — 06.05.2014¶

• Добавлен плагин «Парковка».

1.34.1 — 05.05.2014¶

• Исправлена ошибка загрузки классификационных моделей номеров.

1.34.0 — 01.04.2014¶

• Исправлена ошибка при изменении коэф. для типов номеров.
• Исправлена ошибка с загрузкой файла лицензии.
• Дообучена модель для казахских номеров.

1.33.0 — 12.03.2014¶

• Исправлены ошибки.

1.32.0 — 20.02.2014¶

• Добавлена поддержка ПО «Линия» (http://www.devline.ru).
• Улучшена прорисовка номерного знака.

1.31.0 — 19.02.2014¶

• Добавлено распознавание номеров с трехзначным регионом, начинающимся на 7.
• Добавлено копирование номера версии ПО из формы «О программе. ..».

1.30.0 — 12.02.2014¶

• Для работы необходима библиотека MS .NET Framework 4.5 или выше.

ГИС Аксиома | mapinfo.ru

ГИС Аксиома | mapinfo.ru

ГИС Аксиома

Отечественная ГИС для ОС Windows, Linux, macOS

Совместима с отечественными операционными системами ALT Linux, Astra Linux, РЕД ОС.

Является российской разработкой и зарегистрирована в Едином реестре российских программ для электронных вычислительных машин и баз данных №2174.

Соответствует требованиям сертификации программного обеспечения маркшейдерских работ.

Множество функций и инструментов ГИС Аксиома реализованы аналогично MapInfo Pro. Cовместимость форматов позволяет использовать одни и те же данные для работы в ГИС Аксиома и MapInfo Pro.

Создание и редактирование карт

Инструментарий ГИС Аксиома позволяет эффективно работать с картографической информацией:

• создавать и редактировать пространственные данные

• настраивать оформление объектов и слоев

• получать информацию по объектам карты

• использовать различные системы координат и проекции

• осуществлять поиск и выборку объектов

• выполнять запросы и т. д.

Совместимость с ГИС MapInfo

Множество функций и инструментов ГИС Аксиома реализованы аналогично MapInfo Pro, что обеспечивает легкий переход от MapInfo к Аксиоме, значительно снижая порог вхождения в новое ПО, при знании MapInfo. А совместимость форматов данных предоставляет вам возможность легко перенести ваши проекты из одной программы в другую.

• ГИС Аксиома поддерживает TAB-файлы, созданные в MapInfo Pro.
• Созданные тематические карты в MapInfo Professional и сохранённые в рабочем наборе (.MWS) будут доступны для работы в ГИС Аксиома.
• Проекции, используемые в MapInfo Professional (.PRJ), полностью совместимы со средой ГИС Аксиома.
• Простые SQL-запросы можно переносить из одной программы в другую с помощью QRY-файлов.
• ГИС Аксиома поддерживает все стандартные стили оформления объектов MapInfo Pro.

Данные в различных форматах

ГИС Аксиома поддерживает одновременную работу без конвертации со всеми распространёнными форматами пространственных данных:

• векторные данные в форматах ГИС MapInfo Pro, ESRI,  Панорама, AutoDesk, MicroStation, ERDAS и др.

• аэрофотоснимки, спутниковые снимки, сканированные бумажные карты и т.д.

Безопасность пространственных данных

Для полноценной работы с ГИС Аксиома не требуется подключение к Интернету. Обмен информацией по сети Интернет возможен только по решению пользователя ГИС Аксиома. Пользователь определяет какие данные он хочет получить из Интернета, а также какие данные хочет передать по сети или выложить в Интернет.

Настраиваемый интерфейс

ГИС Аксиома использует два вида интерфейса и позволяет переключаться между ними:

• Ленточный — основанный на панелях инструментов, разделенных вкладками

• «классический» — отображающий строку меню и прикрепляемые панели инструментов

Подробнее

Оформление карт

ГИС Аксиома имеет полный набор средств для оформления карт, включая библиотеки условных обозначений, принятые в Российской Федерации. Имеется редактор стилей линий и заливок площадных объектов.

Тематическое картографирование

Для наглядного представления пространственных данных в ГИС Аксиома используются различные методы построения тематических карт:

• интервалы значений
• столбчатые и круговые диаграммы
• размерные знаки
• отдельные значения
• плотность точек

Хранение и обработка данных в СУБД

ГИС Аксиома работает с PostgreSQL, Microsoft SQL Server, Oracle, SQL Lite:

• подключение к проекту таблицы БД
• поиск и выборка объектов
• работа с таблицами БД напрямую и через временные файлы
• формирование SQL-запросов
• создание тематических карт на основе данных БД
• слияние таблиц по ключевому полю и т.д.

Отчеты

В ГИС Аксиома можно формировать отчеты и выводить их на печать.

В отчет можно включать любую необходимую информацию:

• карты
• таблицы
• тексты
• условные обозначения

Географический анализ

Развитые инструменты географического анализа включают:

• пространственные запросы
• оверлейные операции
• буферные зоны и др.

Картографические web-сервисы

ГИС Аксиома позволяет получить доступ к картографическим web-сервисам WMS, WFS и сервисам тайлов.

Картографические проекции

ГИС Аксиома работает с любыми картографическими проекциями.

В поставку ГИС Аксиома входит более 300 известных картографических проекций, включая российские СК-42, СК-95, ПЗ-90 и ГСК-2011. Также можно задавать собственные проекции.

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

Создание приложений

Пользователи могут расширять функциональность системы и добавлять собственные модули в ГИС Аксиома. Для этого используется язык программирования Python. Справочная система содержит Руководство разработчика.

Рекомендуемые системные требования

64-разрядная операционная система (Windows, Linux, macOS)

Процессор: 2 ГГц и быстрее

RAM: 8 Гбайт (минимум 4 Гбайт)

HDD: 20 Гбайт (минимум 16 Гбайт)

Свидетельство о государственной регистрации

Все права на ГИС Аксиома принадлежат компании ООО «ЭСТИ» — российской компании без иностранного участия.

ГИС Аксиома зарегистрирована в Федеральной службе по интеллектуальной собственности (Роспатент) и выдано свидетельство о государственной регистрации программы для ЭВМ № 2016614626 от 27 апреля 2016 года. 

База данных как объект интеллектуальных прав: чего не хватает в регулировании

Иллюстрация: Право.ru/Петр Козлов

Вызвать такси в один клик, оплатить товары по интернету, выбрать еду в приложении, заказать госуслугу, воспользоваться персональной скидкой — все это возможно благодаря цифровой экономике и базам данных. Их становится все больше, и они нуждаются в правовой защите. Но формулировки норм дают ответы далеко не на все вопросы. В судебной практике тоже нет определенности: самое громкое дело последних лет об использовании базы данных «ВКонтакте» скоро во второй раз рассмотрит Суд по интеллектуальным правам. Нижестоящие инстанции два раза занимали противоположные позиции.

IT-сфера — одна из тех, что сильно опережают право, поэтому правовые конструкции не в полной мере отражают суть современных баз данных, говорит юрист практики IP, патентный поверенный АБ Андрей Городисский и партнеры

Андрей Городисский и партнеры

Федеральный рейтинг.

группа
Интеллектуальная собственность (Консалтинг)

группа
Интеллектуальная собственность (Регистрация)

группа
Налоговое консультирование и споры (Налоговое консультирование)

группа
Трудовое и миграционное право (включая споры)

группа
Интеллектуальная собственность (Защита прав и судебные споры)

Профайл компании

Анатолий Шерстин. А пробелы в правовом регулировании сказываются на защите правообладателей, как будет показано ниже.

Креативные базы

Согласно ч. 2 ст. 1260 ГК, база данных — представленная в объективной форме совокупность самостоятельных материалов (статей, расчетов, нормативных актов и так далее), систематизированных так, чтобы их можно было найти и обработать с помощью электронной вычислительной машины (ЭВМ).

Креативными считают базы, которые признаны составным произведением. Авторские права на такой объект принадлежат «автору, который подобрал или расположил материалы (составительство)». Креативными нельзя назвать базы данных, которые создаются без творческих усилий — пополняются автоматически по алфавиту.

Непонятно, почему законодатель сделал акцент на работе по сбору, обработке и расположению материалов, комментирует старший юрист NEVSKY IP Law

NEVSKY IP Law

Федеральный рейтинг.

группа
Интеллектуальная собственность (Консалтинг)

группа
Интеллектуальная собственность (Регистрация)

группа
Интеллектуальная собственность (Защита прав и судебные споры)

группа
ТМТ (телекоммуникации, медиа и технологии)

Ангелина Скворцова. «За кадром остались те, кто создает контент для конкретной цели, который, по сути, и есть самое важное в базе данных — то, за что люди готовы платить, — объясняет она. — Ценность базы данных, по-моему, как раз не столько в последовательности материалов, а в том, что это за материалы». Положение дел влияет на защиту правообладателей и требует изменить формулировку в ГК, говорит Скворцова.

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

Ангелина Скворцова

Второй вид баз — инвестиционные, о них в следующей карточке. Один и тот же объект может быть зарегистрирован в Роспатенте и как креативный, и как инвестиционный, если отвечает соответствующим признакам.

2

Инвестиционные базы

Речь о базах данных, создание (обработка, представление) которых требует существенных финансовых, материальных, организационных и иных затрат (ч. 1 ст. 1334 ГК). Изготовителю такого объекта принадлежит исключительное право извлекать из него материалы и использовать их любым способом. При отсутствии доказательств иного считается, что требует существенных затрат база, где хранится от 10 000 самостоятельных информационных элементов (материалов).

Неясно, что из себя представляют информационные элементы, говорит старший юрист Versus.legal

Versus.legal

Федеральный рейтинг.

группа
ГЧП/Инфраструктурные проекты

группа
Интеллектуальная собственность (Регистрация)

группа
Интеллектуальная собственность (Защита прав и судебные споры)

группа
Экологическое право

группа
ВЭД/Таможенное право и валютное регулирование

группа
Интеллектуальная собственность (Консалтинг)

группа
Недвижимость, земля, строительство

группа
Ритейл, FMCG, общественное питание

группа
Цифровая экономика

группа
Арбитражное судопроизводство (крупные коммерческие споры — high market)

группа
Банкротство (споры mid market)

группа
Корпоративное право/Слияния и поглощения (mid market)

группа
Разрешение споров в судах общей юрисдикции

группа
ТМТ (телекоммуникации, медиа и технологии)

группа
Частный капитал

Профайл компании

Сергей Ковальков: «Если мы говорим о базе пользователей социальной сети, то что в таком случае является информационным элементом? Карточка с информацией о пользователе или его Ф. И. О.? Если упростить, строчка с информацией о пользователе или одна ячейка с единицей информации?» По мнению Ковалькова, надо уточнить, что считается информационным элементом. Иначе сложно зарегистрировать в Роспатенте или защитить права на базы данных, которые содержат небольшое количество очень информативных карточек.

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

Сергей Ковальков

Если в базе менее 10 000 самостоятельных элементов, понадобится экспертиза. «Но как ее провести, если спор возник в связи с удалением сопартнером такой базы данных и использованием лишь ее самостоятельных элементов? — задается вопросами Скворцова. — Как определить, была ли создана база данных по смыслу ГК?» По мнению юриста, здесь нужно ориентироваться на документы, которыми стороны обменивались до удаления. И не стоит формально подходить к вопросу, была ли создана база данных по смыслу ГК, считает Скворцова.

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

По общему правилу никто не может извлекать из базы данных материалы и использовать их без согласия правообладателя (ч. 1 ст. 1334 ГК). Закон определяет подобный процесс как перенос всего содержания базы данных или существенной части составляющих ее материалов на другой информационный носитель с использованием любых технических средств и в любой форме.

Этой формулировки недостаточно для полной защиты правообладателя баз данных, считает Ковальков. По его словам, закон четко не отвечает на вопрос, можно ли распространять базы, если извлечение материалов было законным (например, по лицензионному договору). Закон запрещает их распространение и использование, если они были незаконно извлечены. Но будет ли считаться виновным лицо, которое на основе лицензионного договора, то есть законно, извлекло данные, а следом отдало их третьим лицам, — задается вопросом Ковальков. Еще одна ситуация посложнее: будет ли считаться нарушителем добросовестно заблуждающееся лицо, купившее базу, которую законно извлекли, но незаконно распространили. Ответов на эти вопросы закон не дает.

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

4

Судебная практика

Судебной практики на эту тему немного, говорят эксперты. Самое известное дело — «ВКонтакте» против «Дабл» (№ А40-18827-2017). Претензии истца связаны с тем, что ответчик использовал базу данных пользователей соцсети и создавал на их основе свои продукты для кредитных организаций, в том числе для сбора информации о заемщиках и оценки их кредитных рисков. Позиция «ВКонтакте» состоит в том, что данные о пользователях — это инвестиционная база данных, куда вложены деньги и усилия сотрудников. Ответчик парирует, что это всего лишь индексация, то есть взаимодействие с соцсетями аналогично поисковикам «Яндекса» и Google, просто его программы ищут лучше, а результат поиска недоступен третьим лицам.

В этом сюжете

• 16 июля, 16:42

Поначалу Арбитражный суд Москвы согласился с этими доводами и отказал в иске о признании действий «Дабла» незаконными. Судьи апелляционного суда, наоборот, признали, что данные извлекались, а именно переносились с одного носителя на другой (ч. 1 ст. 1334 ГК). Суд по интеллектуальным правам направил дело на новое рассмотрение и указал провести судебную экспертизу.

В марте 2021-го АСГМ вновь пришел к выводу, что права истца не нарушаются, а программы ответчика не извлекают информацию и не создают альтернативную базу данных. Апелляция вновь приняла решение в пользу «ВКонтакте» на тех же основаниях, что и в прошлый раз. Теперь слово снова за Судом по интеллектуальным правам, который назначил заседание на 21 сентября 2022 года.

Похожий иск проиграл в 2018 году Head Hunter, который судился с сервисом «Робот Вера» компании «Стафори». Истец требовал пресечь нарушения его права интеллектуальной собственности: ответчик извлекал из базы данных hh.ru резюме и давал доступ к ним без ведома кадрового портала. Ответчик возражал, что сотрудничал с компаниями, которые оплатили доступ к hh.ru, и предоставлял им инструменты для обработки резюме и обзвона соискателей.

Первая инстанция отказала, Мосгорсуд «засилил» ее решение (дело № 33-34020/2018). По их мнению, истец не доказал, что ответчик, «Стафори», пользовался доступом к закрытой (платной) части базы данных резюме или давал пользователям этот доступ. Суды сослались на п. 3 ст. 1335.1 ГК. Согласно ей, нарушением считается не просто неоднократное извлечение или использование материалов базы данных, но и противоречие таких действий нормальному использованию базы данных и ущемление необоснованным образом законных интересов изготовителя базы данных. Таких фактов Head Hunter не доказал, решили суды.

О вопросе законности скрейпинга, то есть получения «больших данных» из баз с других сайтов, рассуждает партнер Гардиум

Гардиум

Федеральный рейтинг.

группа
Интеллектуальная собственность (Защита прав и судебные споры)

группа
Интеллектуальная собственность (Регистрация)

группа
Интеллектуальная собственность (Консалтинг)

группа
Ритейл, FMCG, общественное питание

группа
Цифровая экономика

12место
По выручке

Арина Ворожевич. Если скрейпер-конкурент создает альтернативный правообладателю продукт, обходит технические блокировки, а в пользовательском соглашении есть запрет скрейпинга и парсинга, то это нарушение, считает эксперт, указывая на практику США и ЕС.

А в деле № А07-25365/2020 суды давали квалификацию договору 2015 года на совместное создание базы данных «Документы по оформлению и управлению интеллектуальной собственностью». По соглашению, ОДО «Юридическое общество Александра Невского» организовывало процесс создания результатов интеллектуальной деятельности и ее самостоятельных элементов, сбор, обработку, расположение материалов, координацию работы авторов (80% работы). «Доклаб» брало на себя разработку базы данных, проверку элементов, обеспечивало работу базы на своем программном обеспечении (20% работы). Доходы договорились делить пополам, но ОДО решило, что «Доклаб» задолжал ему порядка полумиллиона выплат.

Суды квалифицировали сделку как договор простого товарищества (гл. 55 ГК) — соединение вкладов и совместные действия двух или более лиц без образования юридического лица для извлечения прибыли или другой законной цели. Суды отклонили доводы ответчика, что в соглашении есть элементы договора авторского заказа. Еще он указывал, что речь идет о договоре возмездного оказания услуг, а именно о разработке рабочих материалов по теме. Но судьи не приняли его доводы, указав, в частности, на условие о распределении прибыли поровну. Таким образом, договор заключен и долг надо выплатить, заключили суды.

12 июля Суд по интеллектуальным правам оставил решения без изменения.

• Интеллектуальная собственность

Учебник

. Георепликация и отработка отказа на портале — База данных SQL Azure

Редактировать

Твиттер

LinkedIn

Фейсбук

Электронная почта

• Статья
• 03. 03.2023
• 5 минут на чтение

Применимо к:
База данных SQL Azure

В этой статье показано, как настроить активную георепликацию для базы данных SQL Azure с помощью портала Azure или Azure CLI и инициировать отработку отказа.

Рекомендации по использованию групп автоматической отработки отказа см. в разделах Группы автоматической отработки отказа с базой данных SQL Azure и Группы автоматической отработки отказа с Управляемым экземпляром SQL Azure.

Предпосылки

• Портал
• Azure CLI

Чтобы настроить активную георепликацию с помощью портала Azure, вам потребуется следующий ресурс:

• База данных в базе данных SQL Azure: первичная база данных, которую вы хотите реплицировать в другой географический регион.

Примечание

При использовании портала Azure вы можете создать дополнительную базу данных только в той же подписке, что и основная. Если база данных-получатель должна находиться в другой подписке, используйте REST API Create Database или ALTER DATABASE Transact-SQL API.

Добавление базы данных-получателя

Следующие шаги создают новую базу данных-получатель в партнерстве георепликации.

Чтобы добавить базу данных-получатель, вы должны быть владельцем или совладельцем подписки.

База данных-получатель имеет то же имя, что и база данных-источник, и по умолчанию имеет тот же уровень служб и объем вычислений. База данных-получатель может быть одиночной базой данных или базой данных в пуле. Дополнительные сведения см. в разделах Модель приобретения на основе DTU и Модель приобретения на основе виртуального ядра.
После создания и заполнения базы данных-получателя данные начинают реплицироваться из базы данных-источника в новую базу данных-получатель.

Примечание

Если партнерская база данных уже существует (например, в результате прекращения предыдущей связи георепликации), команда завершается ошибкой.

• Портал
• Azure CLI

1. На портале Azure перейдите к базе данных, которую вы хотите настроить для георепликации.

2. На странице базы данных SQL выберите свою базу данных, прокрутите до Управление данными , выберите Реплики , а затем выберите Создать реплику .

3. Выберите или создайте сервер для базы данных-получателя и настройте Вычислительные ресурсы + хранилище варианты, если необходимо. Вы можете выбрать любой регион для своего вторичного сервера, но мы рекомендуем парный регион.

   При необходимости вы можете добавить базу данных-получатель в эластичный пул. Чтобы создать базу данных-получатель в пуле, выберите Да рядом с Хотите использовать эластичный пул SQL? и выберите пул на целевом сервере. Пул должен уже существовать на целевом сервере. Этот рабочий процесс не создает пул.

4. Нажмите Просмотреть + создать , просмотрите информацию и нажмите Создать .

5. База данных-получатель создана, и начинается процесс развертывания.

6. По завершении развертывания база данных-получатель отображает свое состояние.

7. Вернитесь на страницу первичной базы данных и выберите Реплики . Ваша база данных-получатель указана в списке Geo replicas .

Инициировать отработку отказа

Вторичная база данных может стать основной.

• Портал
• Azure CLI

1. На портале Azure перейдите к базе данных-источнику в партнерстве георепликации.

2. Прокрутите до Управление данными и выберите Реплики .

3. В списке Geo replicas выберите базу данных, которую вы хотите сделать новой первичной, щелкните многоточие, а затем выберите Принудительный переход на другой ресурс .

4. Выберите Да , чтобы начать аварийное переключение.

Эта команда немедленно переключает базу данных-получатель в основную роль. Этот процесс обычно должен завершиться в течение 30 секунд или меньше.

Существует короткий период, в течение которого обе базы данных недоступны, порядка 0-25 секунд, пока роли меняются. Если первичная база данных имеет несколько вторичных баз данных, команда автоматически перенастраивает другие вторичные базы данных для подключения к новой первичной базе данных. В нормальных условиях вся операция должна занять менее минуты.

Примечание

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

Удаление базы данных-получателя

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

• Портал
• Azure CLI

1. На портале Azure перейдите к базе данных-источнику в партнерстве георепликации.
2. Выберите реплик .
3. В списке Георепликации выберите базу данных, которую вы хотите удалить из партнерства георепликации, щелкните многоточие, а затем выберите Остановить репликацию .
4. Откроется окно подтверждения. Щелкните Да , чтобы удалить базу данных из партнерства георепликации. (Установите его в базу данных для чтения и записи, не являющуюся частью какой-либо репликации.)

Следующие шаги

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

.

• Обзор и сценарии непрерывности бизнеса см. в разделе Обзор непрерывности бизнеса.

Обратная связь

Просмотреть все отзывы о странице

Активная георепликация — База данных SQL Azure

• Статья
• 03. 03.2023
• 19 минут на чтение

Применимо к:
База данных SQL Azure

Активная георепликация — это функция, которая позволяет создавать постоянно синхронизируемую доступную для чтения базу данных-получатель для базы данных-источника. База данных-получатель, доступная для чтения, может находиться в том же регионе Azure, что и основная база данных, или, что чаще, в другом регионе. Этот тип вторичной базы данных, доступной для чтения, также известен как геовторичная или геореплика.

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

Примечание

Для географической отработки отказа экземпляров Управляемого экземпляра SQL используйте группы автоматической отработки отказа. Дополнительные сведения см. в статье Сравнение георепликации с группами отработки отказа. Активная георепликация не поддерживается Управляемым экземпляром Azure SQL.

Примечание

Сведения о переносе баз данных SQL из Azure для Германии с использованием активной георепликации см. в разделе Миграция базы данных SQL с использованием активной георепликации.

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

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

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

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

• Портал Azure
• PowerShell: одна база данных
• PowerShell: эластичный пул
• Transact-SQL: отдельная база данных или эластичный пул
• REST API: одна база данных

Активная георепликация использует технологию группы доступности Always On для асинхронной репликации журнала транзакций, созданного на первичной реплике, во все георепликации. Хотя в любой момент база данных-получатель может немного отставать от базы данных-источника, данные в базе данных-получателе гарантированно будут транзакционно непротиворечивыми. Другими словами, изменения, сделанные незафиксированными транзакциями, не видны.

Примечание

Активная георепликация реплицирует изменения путем потоковой передачи журнала транзакций базы данных из первичной реплики во вторичные реплики. Это не связано с репликацией транзакций, которая реплицирует изменения, выполняя команды DML (INSERT, UPDATE, DELETE) на подписчиках.

Региональная избыточность, обеспечиваемая георепликацией, позволяет приложениям быстро восстанавливаться после необратимой потери всего региона Azure или его частей, вызванной стихийными бедствиями, катастрофическими человеческими ошибками или злонамеренными действиями. RPO георепликации можно найти в обзоре непрерывности бизнеса.

На следующем рисунке показан пример активной георепликации, настроенной с первичным сервером в центрально-северном регионе США и геодополнительным в регионе центрально-южного региона США.

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

• Миграция базы данных : активную георепликацию можно использовать для миграции базы данных с одного сервера на другой с минимальным временем простоя.
• Обновления приложений : Вы можете создать дополнительную вторичную копию в качестве резервной копии во время обновления приложения.

Для обеспечения полной непрерывности бизнеса добавление региональной избыточности базы данных является лишь частью решения. Полное восстановление приложения (службы) после катастрофического сбоя требует восстановления всех компонентов, составляющих службу, и любых зависимых служб. Примеры этих компонентов включают клиентское программное обеспечение (например, браузер с пользовательским JavaScript), веб-интерфейсы, хранилище и DNS. Крайне важно, чтобы все компоненты были устойчивы к одним и тем же сбоям и были доступны в течение целевого времени восстановления (RTO) вашего приложения. Поэтому вам необходимо определить все зависимые службы и понять гарантии и возможности, которые они предоставляют. Затем вы должны предпринять соответствующие шаги, чтобы убедиться, что ваша служба работает во время отработки отказа служб, от которых она зависит. Дополнительные сведения о разработке решений для аварийного восстановления см. в разделе Разработка облачных решений для аварийного восстановления с использованием активной георепликации.

Терминология и возможности активной георепликации

• Автоматическая асинхронная репликация

  Вы можете создать вторичную геоданную только для существующей базы данных. Геовторичную базу данных можно создать на любом логическом сервере, кроме сервера с первичной базой данных. После создания вторичная геореплика заполняется данными первичной базы данных. Этот процесс известен как посев. После создания и заполнения геовторичной базы данных обновления первичной базы данных автоматически и асинхронно реплицируются на геовторичную реплику. Асинхронная репликация означает, что транзакции фиксируются в базе данных-источнике до того, как они будут реплицированы.

• Доступные для чтения геовторичные реплики

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

  Важно

  Вы можете использовать георепликацию для создания вторичных реплик в том же регионе, что и первичная. Эти вторичные серверы можно использовать для выполнения сценариев горизонтального масштабирования чтения в том же регионе. Однако вторичная реплика в том же регионе не обеспечивает дополнительной устойчивости к катастрофическим сбоям или крупномасштабным сбоям и, следовательно, не является подходящей целью аварийного переключения для целей аварийного восстановления. Это также не гарантирует изоляцию зоны доступности. Используйте избыточную конфигурацию зоны уровней служб Business Critical или Premium или избыточную конфигурацию зоны уровня служб общего назначения, чтобы добиться изоляции зоны доступности.

• Запланированный отказоустойчивый режим

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

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

• Незапланированный отказоустойчивый режим

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

  Важно

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

• Несколько читаемых гео-вторичных данных

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

  Совет

  Если вы используете активную георепликацию для создания глобально распределенного приложения и вам необходимо предоставить доступ только для чтения к данным в более чем четырех регионах, вы можете создать вторичный вторичный (процесс, известный как цепочка) для создавать дополнительные геореплики. Задержка репликации на связанных георепликах может быть выше, чем на георепликах, подключенных непосредственно к первичной реплике. Настройка связанных топологий георепликации поддерживается только программно, а не на портале Azure.

• Георепликация баз данных в эластичном пуле

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

• Управляемое пользователем географическое аварийное переключение и восстановление после отказа

  Приложение или пользователь может в любой момент явно переключить на первичную роль геодополнительный сервер, завершивший начальное заполнение. Во время сбоя, когда первичный сервер недоступен, можно использовать только незапланированное геоотказоустойчивое переключение. Это немедленно способствует тому, чтобы гео-вторичный объект стал новым первичным. Когда сбой устраняется, система автоматически делает восстановленный основной сервер геодополнительным и обновляет его с помощью нового основного источника. Из-за асинхронного характера георепликации последние транзакции могут быть потеряны во время незапланированных отказоустойчивых геоданных, если первичный сервер выйдет из строя до того, как эти транзакции будут реплицированы на геодополнительный. Когда первичный сервер с несколькими геодополнительными серверами отказывает, система автоматически перенастраивает отношения репликации и связывает оставшиеся геодополнительные серверы с вновь повышенным основным сервером, не требуя вмешательства пользователя. После того как сбой, вызвавший отказоустойчивость, устранен, может потребоваться вернуть основной сервер в исходный регион. Для этого вызовите запланированную гео-отказоустойчивость.

Подготовка к гео-отказоустойчивости

Чтобы ваше приложение могло сразу получить доступ к новому первичному серверу после гео-отработки отказа, убедитесь, что проверка подлинности и сетевой доступ для вашего вторичного сервера настроены правильно. Дополнительные сведения см. в разделе Безопасность базы данных SQL после аварийного восстановления. Также убедитесь, что политика хранения резервных копий в базе данных-получателе совпадает с политикой хранения первичной. Этот параметр не является частью базы данных и не реплицируется с первичной. По умолчанию для вторичного геоданных настроен период хранения PITR по умолчанию, равный семи дням. Дополнительные сведения см. в разделе Автоматическое резервное копирование базы данных SQL.

Важно

Если ваша база данных является членом группы отработки отказа, вы не можете инициировать ее отработку отказа с помощью команды переключения при отказе георепликации. Используйте команду аварийного переключения для группы. Если вам нужно выполнить отработку отказа отдельной базы данных, вы должны сначала удалить ее из группы отработки отказа. Дополнительные сведения см. в разделе Группы автоматической отработки отказа.

Настройка геодополнительного

И первичный, и геодополнительный должны иметь один и тот же уровень обслуживания. Также настоятельно рекомендуется, чтобы гео-вторичный сервер был настроен с той же избыточностью хранилища резервных копий и размером вычислительных ресурсов (DTU или виртуальных ядер), что и первичный. Если первичный сервер испытывает большую рабочую нагрузку по записи, геодополнительный сервер с меньшим объемом вычислений может не справиться. Это приведет к задержке репликации на геовторичном сервере и в конечном итоге может привести к его недоступности. Чтобы снизить эти риски, активная георепликация уменьшит (дросселирует) скорость журнала транзакций первичного сервера, если это необходимо, чтобы позволить его вторичным серверам наверстать упущенное.

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

Если вы решите создать геовторичный сервер с меньшим объемом вычислительных ресурсов, вам следует отслеживать скорость ввода-вывода журнала на первичном сервере с течением времени. Это позволяет оценить минимальный объем вычислительных ресурсов геовторичного сервера, необходимый для поддержания нагрузки репликации. Например, если ваша первичная база данных — P6 (1000 DTU) и ее ввод-вывод журнала поддерживается на уровне 50 %, геодополнительная база данных должна быть не ниже P4 (500 DTU). Чтобы получить исторические данные журнала операций ввода-вывода, используйте представление sys.resource_stats. Чтобы получить последние данные журнала операций ввода-вывода с более высокой степенью детализации, которые лучше отражают краткосрочные всплески, используйте представление sys.dm_db_resource_stats.

Совет

Журнал транзакций О регулировании ввода-вывода на первичном сервере из-за меньшего объема вычислений на геодополнительном сервере сообщается с использованием типа ожидания HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO, видимого в представлениях базы данных sys.dm_exec_requests и sys.dm_os_wait_stats.

Операции ввода-вывода журнала транзакций на первичном сервере могут регулироваться по причинам, не связанным с меньшим объемом вычислений на геодополнительном. Такой тип регулирования может иметь место, даже если геодополнительный сервер имеет такой же или больший объем вычислений, чем первичный. Дополнительные сведения, включая типы ожидания для различных видов регулирования ввода-вывода журнала, см. в разделе Управление скоростью журнала транзакций.

По умолчанию избыточность хранилища резервных копий геовторичной базы данных такая же, как и для первичной базы данных. Вы можете настроить гео-вторичное хранилище с другой избыточностью хранилища резервных копий. Резервные копии всегда создаются в первичной базе данных. Если вторичное хранилище настроено с другой избыточностью хранилища резервных копий, то после геоотработки отказа, когда геовторичное хранилище становится первичным, новые резервные копии будут храниться и оплачиваться в соответствии с типом хранилища (RA-GRS, ZRS, LRS), выбранный на новом первичном (предыдущем вторичном).

Георепликация между подписками

Чтобы создать геодополнительную подписку в подписке, отличной от подписки первичной (независимо от того, находится ли она в том же клиенте Azure Active Directory или нет), выполните действия, описанные в этом разделе.

1. Добавьте IP-адрес клиентского компьютера, выполняющего приведенные ниже команды T-SQL, к брандмауэрам сервера как основного, так и вторичного серверов. Вы можете подтвердить этот IP-адрес, выполнив следующий запрос при подключении к основному серверу с того же клиентского компьютера.

    выберите client_net_address из sys.dm_exec_connections, где session_id = @@SPID;
    

   Дополнительные сведения см. в разделе Настройка брандмауэра.

2. В базе данных master на первичном сервере создайте имя входа для проверки подлинности SQL, предназначенное для активной настройки георепликации. При необходимости измените имя пользователя и пароль.

    создать логин geodrsetup с паролем = 'ComplexPassword01';
    

3. В той же базе создайте пользователя для логина и добавьте его в список dbmanager роль:

    создать пользователя geodrsetup для входа в систему geodrsetup;
   изменить роль dbmanager добавить члена geodrsetup;
    

4. Запишите значение SID нового входа. Получите значение SID, используя следующий запрос.

    выберите sid из sys. sql_logins, где имя = 'geodrsetup';
    

5. Подключитесь к первичной базе данных (не к базе данных master ) и создайте пользователя для того же входа.

    создать пользователя geodrsetup для входа в систему geodrsetup;
    

6. В той же базе данных добавьте пользователя в роль db_owner .

    изменить роль db_owner добавить члена geodrsetup;
    

7. В базе данных master на вторичном сервере создайте тот же логин, что и на первичном сервере, используя то же имя, пароль и SID. Замените шестнадцатеричное значение SID в приведенном ниже образце команды значением, полученным на шаге 4.

    создать логин geodrsetup с паролем = 'ComplexPassword01', sid = 0x010600000000006400000000000000001C98F52B95D9C84BBBA8578FACE37C3E;
    

8. В той же базе данных создайте пользователя для входа в систему и добавьте его в роль dbmanager .

    создать пользователя geodrsetup для входа в систему geodrsetup;
   изменить роль dbmanager добавить члена geodrsetup;
    

9. Подключитесь к базе данных master на первичном сервере , используя новый логин geodrsetup , и инициируйте создание дополнительного геодополнительного объекта на вторичном сервере. При необходимости измените имя базы данных и имя вторичного сервера. После выполнения команды вы можете отслеживать создание геовторичных ресурсов, запрашивая представление sys.dm_geo_replication_link_status в первичная база данных и представление sys.dm_operation_status в основной базе данных на первичном сервере . Время, необходимое для создания геодополнительной базы данных, зависит от размера основной базы данных.

    изменить базу данных [dbrep] добавить вторичный сервер на сервер [имя_сервера];
    

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

Примечание

Операции георепликации между подписками, включая настройку и географическую отработку отказа, поддерживаются только с помощью REST API и команд T-SQL.

Добавление геодополнительного сервера с помощью T-SQL не поддерживается при подключении к первичному серверу через частную конечную точку. Если настроена частная конечная точка, но разрешен доступ к общедоступной сети, добавление геодополнительной точки поддерживается при подключении к основному серверу с общедоступного IP-адреса. После добавления геодополнительного доступа доступ к общедоступной сети может быть запрещен.

Создание геодополнительного сервера на логическом сервере в другом арендаторе Azure не поддерживается, если активна (включена) только проверка подлинности Azure Active Directory для Azure SQL на основном или дополнительном логическом сервере.

Синхронизируйте учетные данные и правила брандмауэра

При использовании доступа к общедоступной сети для подключения к базе данных мы рекомендуем использовать правила брандмауэра IP на уровне базы данных для геореплицированных баз данных. Эти правила реплицируются с базой данных, что гарантирует, что все геодополнительные устройства имеют те же правила IP-брандмауэра, что и основной. Такой подход избавляет клиентов от необходимости вручную настраивать и поддерживать правила брандмауэра на серверах, на которых размещены первичная и вторичная базы данных. Точно так же использование пользователей автономной базы данных для доступа к данным гарантирует, что первичная и вторичная базы данных всегда будут иметь одни и те же учетные данные для аутентификации. Таким образом, после геоотработки отказа не будет сбоев из-за несоответствия учетных данных аутентификации. Если вы используете логины и пользователей (а не содержащихся пользователей), вы должны предпринять дополнительные шаги, чтобы убедиться, что те же логины существуют для вашей базы данных-получателя. Подробнее о конфигурации см. в разделе Как настроить логины и пользователей.

Масштабирование первичной базы данных

Вы можете масштабировать первичную базу данных до другого объема вычислений (в пределах того же уровня служб), не отключая какие-либо геодополнительные серверы. При масштабировании мы рекомендуем сначала масштабировать геодополнительную, а затем первичную. При уменьшении масштаба действуйте в обратном порядке: сначала уменьшите основной, а затем второстепенный.

Примечание

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

Важно

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

Исходная база данных «Primaryserver. DBName» не может иметь выпуск выше, чем целевая база данных «Secondaryserver.DBName». . Обновите выпуск на цели перед обновлением источника.

Предотвращение потери важных данных

Из-за высокой задержки глобальных сетей георепликация использует механизм асинхронной репликации. Асинхронная репликация делает неизбежным возможность потери данных в случае сбоя основного. Чтобы защитить важные транзакции от потери данных, разработчик приложения может вызвать хранимую процедуру sp_wait_for_database_copy_sync сразу после фиксации транзакции. Вызов sp_wait_for_database_copy_sync блокирует вызывающий поток до тех пор, пока последняя зафиксированная транзакция не будет передана и закреплена в журнале транзакций базы данных-получателя. Однако он не ждет, пока переданные транзакции будут воспроизведены (повторно выполнены) на вторичном сервере. sp_wait_for_database_copy_sync относится к конкретной ссылке георепликации. Эту процедуру может вызвать любой пользователь с правами на подключение к первичной базе данных.

Примечание

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

Отслеживание задержки георепликации

Для отслеживания задержки по отношению к RPO используйте столбец replication_lag_sec в sys.dm_geo_replication_link_status в базе данных-источнике. Он показывает задержку в секундах между транзакциями, зафиксированными на первичном сервере, и зафиксированными в журнале транзакций на вторичном сервере. Например, если задержка составляет одну секунду, это означает, что если в этот момент произойдет сбой основного сервера и будет инициировано гео-отказоустойчивость, транзакции, совершенные в последнюю секунду, будут потеряны.

Чтобы измерить задержку в отношении изменений в базе данных-источнике, которые были усилены на гео-вторичной базе данных, сравните last_commit время на гео-вторичной базе данных с тем же значением на первичной.

Совет

Если replication_lag_sec на первичном сервере имеет значение NULL, это означает, что первичный сервер в настоящее время не знает, насколько далеко он отстает от геодополнительного. Обычно это происходит после перезапуска процесса и должно быть временным состоянием. Рассмотрите отправку оповещения, если replication_lag_sec возвращает NULL в течение длительного периода времени. Это может указывать на то, что геодополнительный сервер не может связаться с основным из-за сбоя подключения.

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

Программное управление активной георепликацией

Как обсуждалось ранее, активной георепликацией также можно управлять программно с помощью T-SQL, Azure PowerShell и REST API. В следующих таблицах описывается набор доступных команд. Активная георепликация включает набор API-интерфейсов Azure Resource Manager для управления, включая REST API базы данных SQL Azure и командлеты Azure PowerShell. Эти API поддерживают управление доступом на основе ролей Azure (Azure RBAC). Дополнительные сведения о реализации ролей доступа см. в разделе Управление доступом на основе ролей Azure (Azure RBAC).

T-SQL: управление отказоустойчивостью отдельных баз данных и баз данных в пуле

Важно

Эти команды T-SQL применяются только к активной георепликации и не применяются к группам отработки отказа. Таким образом, они также не применяются к управляемому экземпляру SQL, который поддерживает только группы отработки отказа.

Команда	Описание
ИЗМЕНИТЬ БАЗУ ДАННЫХ	Используйте аргумент ADD SECONDARY ON SERVER , чтобы создать базу данных-получатель для существующей базы данных и запустить репликацию данных
ИЗМЕНИТЬ БАЗУ ДАННЫХ	Используйте FAILOVER или FORCE_FAILOVER_ALLOW_DATA_LOSS , чтобы переключить базу данных-получатель на первичную, чтобы инициировать отработку отказа
ИЗМЕНИТЬ БАЗУ ДАННЫХ	Используйте команду REMOVE SECONDARY ON SERVER , чтобы завершить репликацию данных между базой данных SQL и указанной базой данных-получателем.
sys.geo_replication_links	Возвращает информацию обо всех существующих ссылках репликации для каждой базы данных на сервере.
sys.dm_geo_replication_link_status	Получает время последней репликации, последнюю задержку репликации и другую информацию о ссылке репликации для данной базы данных.
sys.dm_operation_status	Показывает состояние всех операций базы данных, включая изменения ссылок репликации.
sys.sp_wait_for_database_copy_sync	Заставляет приложение ждать, пока все совершенные транзакции не будут закреплены в журнале транзакций гео-вторичного хранилища.

PowerShell: управление отказоустойчивостью отдельных баз данных и баз данных в пулах

Примечание

В этой статье используется модуль Azure Az PowerShell, рекомендуемый модуль PowerShell для взаимодействия с Azure. Чтобы начать работу с модулем Az PowerShell, см. раздел Установка Azure PowerShell. Чтобы узнать, как перейти на модуль Az PowerShell, см. статью Миграция Azure PowerShell из AzureRM в Az.

Important Важно!

Модуль PowerShell Azure Resource Manager по-прежнему поддерживается базой данных SQL Azure, но все будущие разработки относятся к модулю Az.Sql. Эти командлеты см. в разделе AzureRM. Sql. Аргументы для команд в модуле Az и в модулях AzureRm практически идентичны.

Совет

Примеры сценариев см. в разделах Настройка и отработка отказа отдельной базы данных с использованием активной георепликации и Настройка и отработка отказа базы данных в пуле с использованием активной георепликации.

REST API: управление отказоустойчивостью отдельных баз данных и баз данных в составе пула

API	Описание
Создать или обновить базу данных (createMode=Restore)	Создает, обновляет или восстанавливает первичную или вторичную базу данных.
Получить статус создания или обновления базы данных	Возвращает статус во время операции создания.
Установить вторичную базу данных в качестве основной (запланированный переход на другой ресурс)	Указывает, какая база данных-получатель является основной, путем переключения с текущей базы данных-источника. Этот параметр не поддерживается для Управляемого экземпляра SQL.
Установка вторичной базы данных в качестве первичной (незапланированная отработка отказа)	Указывает, какая база данных-получатель является основной, путем переключения с текущей базы данных-источника. Эта операция может привести к потере данных. Этот параметр не поддерживается для Управляемого экземпляра SQL.
Получить ссылку репликации	Получает конкретную ссылку репликации для заданной базы данных в партнерстве георепликации. Он извлекает информацию, видимую в представлении каталога sys.geo_replication_links. Этот параметр не поддерживается для Управляемого экземпляра SQL.
Ссылки репликации — список по базе данных	Получает все ссылки репликации для заданной базы данных в партнерстве георепликации. Он извлекает информацию, видимую в представлении каталога sys.geo_replication_links.
Удалить ссылку репликации	Удаляет ссылку репликации базы данных. Невозможно выполнить во время отработки отказа.

Следующие шаги

• Примеры сценариев см. по адресу:
  • Настройка и отработка отказа одной базы данных с использованием активной георепликации.
  • Настройка и отработка отказа базы данных в пуле с использованием активной георепликации.

База данных SQL

• также поддерживает группы автоматической отработки отказа. Дополнительные сведения см. в разделе Использование групп автоматической отработки отказа.
• Обзор и сценарии непрерывности бизнеса см. в разделе Обзор непрерывности бизнеса.
• Дополнительные сведения об автоматическом резервном копировании базы данных SQL Azure см. в разделе Автоматическое резервное копирование базы данных SQL.
• Дополнительные сведения об использовании автоматического резервного копирования для восстановления см. в разделе Восстановление базы данных из резервных копий, инициированных службой.
• Чтобы узнать о требованиях проверки подлинности для нового основного сервера и базы данных, см. раздел Безопасность базы данных SQL после аварийного восстановления.

remove-from-global-cluster — AWS CLI 1.27.84 Справочник по командам

Примечание:
Вы просматриваете документацию для более старой основной версии интерфейса командной строки AWS (версия 1).

AWS CLI версии 2, последняя основная версия AWS CLI, теперь стабильна и рекомендуется для общего использования.

Чтобы просмотреть эту страницу для AWS CLI версии 2, нажмите
здесь.

Дополнительные сведения см. в интерфейсе командной строки AWS версии 2.
Инструкция по установке
и
руководство по миграции.

[ авс . rds ]

Описание

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

Примечание

Это действие применимо только к кластерам БД Aurora.

См. также: Документация по API AWS

Краткий обзор

 удалить-из-глобального-кластера
[--global-cluster-identifier <значение>]
[--db-кластерный идентификатор <значение>]
[--cli-input-json <значение>]
[--generate-cli-скелет <значение>]
[--отлаживать]
[--endpoint-url <значение>]
[--no-проверить-ssl]
[--без разбивки на страницы]
[--выход <значение>]
[--запрос <значение>]
[--профиль <значение>]
[--регион <значение>]
[--версия <значение>]
[--цвет <значение>]
[--нет-знака-запроса]
[--ca-комплект <значение>]
[--cli-read-timeout <значение>]
[--cli-connect-timeout <значение>]
 

Опции

--global-cluster-identifier (строка)

Идентификатор кластера для отключения от кластера глобальной базы данных Aurora.

--db-cluster-identifier (строка)

Имя ресурса Amazon (ARN), идентифицирующее кластер, который был отсоединен от кластера глобальной базы данных Aurora.

--cli-input-json (строка)
Выполняет операцию службы на основе предоставленной строки JSON. Строка JSON соответствует формату, предоставленному --генерировать-кли-скелет . Если в командной строке указаны другие аргументы, значения CLI переопределяют значения, предоставленные JSON. Невозможно передать произвольные двоичные значения, используя значение, предоставленное JSON, поскольку строка будет воспринята буквально.

--generate-cli-skeleton (строка)
Печатает скелет JSON в стандартный вывод без отправки запроса API. Если указано без значения или со значением input , печатает образец ввода JSON, который можно использовать в качестве аргумента для --cli-ввод-json . Если указано значение output , он проверяет входные данные команды и возвращает образец вывода JSON для этой команды.

Глобальные параметры

--debug (логическое)

Включить ведение журнала отладки.

--endpoint-url (строка)

Переопределить URL-адрес команды по умолчанию с заданным URL-адресом.

--no-verify-ssl (логическое значение)

По умолчанию интерфейс командной строки AWS использует SSL при обмене данными с сервисами AWS. Для каждого соединения SSL интерфейс командной строки AWS будет проверять сертификаты SSL. Этот параметр переопределяет стандартное поведение проверки SSL-сертификатов.

--no-paginate (логическое значение)

Отключить автоматическое разбиение на страницы.

--output (строка)

Стиль форматирования вывода команды.

• json
• текст
• стол

--query (строка)

Запрос JMESPath для использования при фильтрации данных ответа.

--profile (строка)

Используйте определенный профиль из вашего файла учетных данных.

--region (строка)

Используемый регион. Переопределяет настройки config/env.

--version (строка)

Показать версию этого инструмента.

--color (строка)

Включить/выключить цветной вывод.

• на
• от
• авто

--no-sign-request (логическое)

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

--ca-bundle (string)

Пакет сертификатов CA для использования при проверке SSL-сертификатов. Переопределяет настройки config/env.

--cli-read-timeout (целое)

Максимальное время чтения сокета в секундах. Если установлено значение 0, чтение сокета будет блокироваться, а не по тайм-ауту. Значение по умолчанию — 60 секунд.

--cli-connect-timeout (int)

Максимальное время подключения к сокету в секундах. Если установлено значение 0, подключение к сокету будет блокироваться, а не по тайм-ауту. Значение по умолчанию — 60 секунд.

Примеры

Примечание

Чтобы использовать следующие примеры, необходимо установить и настроить интерфейс командной строки AWS. Дополнительную информацию см. в руководстве по началу работы в AWS CLI User Guide .

Если не указано иное, все примеры имеют unix-подобные правила кавычек. Эти примеры нужно будет адаптировать к правилам котирования вашего терминала. См. Использование кавычек со строками в AWS CLI User Guide .

Чтобы отсоединить вторичный кластер Aurora от кластера глобальной базы данных Aurora

В следующем примере remove-from-global-cluster вторичный кластер Aurora отсоединяется от кластера глобальной базы данных Aurora. Кластер из режима только для чтения становится автономным кластером с возможностью чтения и записи.

 aws rds удалить из глобального кластера \
    --регион сша-запад-2 \
    --global-cluster-identifier myglobalcluster \
    --db-cluster-identifier arn:aws:rds:us-west-2:123456789012:cluster:DB-1
 

Вывод:

 {
    "ГлобалКластер": {
        "GlobalClusterIdentifier": "myglobalcluster",
        "GlobalClusterResourceId": "кластер-abc123def456gh",
        "GlobalClusterArn": "arn:aws:rds::123456789012: глобальный кластер: мой глобальный кластер",
        «Статус»: «в наличии»,
        "Движок": "аврора-postgresql",
        «Версия двигателя»: «10. 11»,
        "StorageEncrypted": правда,
        «Защита от удаления»: ложь,
        "Глобальные члены кластера": [
            {
                "DBClusterArn": "arn:aws:rds:us-east-1:123456789012:cluster:js-global-cluster",
                "Читатели": [
                    "arn:aws:rds:us-west-2:123456789012:cluster:DB-1"
                ],
                "Исписатель": правда
            },
            {
                "DBClusterArn": "arn:aws:rds:us-west-2:123456789012:кластер:DB-1",
                «Читатели»: [],
                "IsWriter": ложь,
                «GlobalWriteForwardingStatus»: «отключено»
            }
        ]
    }
}
 

Дополнительные сведения см. в разделе Удаление кластера из глобальной базы данных Amazon Aurora в Руководстве пользователя Amazon Aurora .

Выход

GlobalCluster -> (структура)

Тип данных, представляющий глобальную базу данных Aurora.

GlobalClusterIdentifier -> (строка)

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

GlobalClusterResourceId -> (строка)

Уникальный для региона неизменяемый идентификатор Amazon Web Services для кластера глобальной базы данных. Этот идентификатор можно найти в записях журнала Amazon Web Services CloudTrail при каждом доступе к ключу KMS Amazon Web Services для кластера БД.

GlobalClusterArn -> (строка)

Имя ресурса Amazon (ARN) для кластера глобальной базы данных.

Статус -> (строка)

Указывает текущее состояние этого глобального кластера базы данных.

Двигатель -> (строка)

Механизм базы данных Aurora, используемый кластером глобальной базы данных.

EngineVersion -> (строка)

Указывает версию ядра базы данных.

Имя базы данных -> (строка)

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

StorageEncrypted -> (логическое значение)

Параметр шифрования хранилища для кластера глобальной базы данных.

Защита от удаления -> (логическое значение)

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

GlobalClusterMembers -> (список)

Список идентификаторов кластеров для вторичных кластеров в кластере глобальной базы данных. На данный момент ограничено 1 шт.

(структура)

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

DBClusterArn -> (строка)

Имя ресурса Amazon (ARN) для каждого кластера Aurora.

Читатели -> (список)

Имя ресурса Amazon (ARN) для каждого вторичного кластера, доступного только для чтения, связанного с глобальной базой данных Aurora.

(строка)

IsWriter -> (логическое значение)

Указывает, является ли кластер Aurora основным кластером (т. е. имеет возможность чтения и записи) для глобальной базы данных Aurora, с которой он связан.

GlobalWriteForwardingStatus -> (строка)

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

Состояние отказа -> (структура)

Объект данных, содержащий все свойства текущего состояния внутрипроцессного или ожидающего обработки отказа для этой глобальной базы данных Aurora. Этот объект пуст, если для этой глобальной базы данных Aurora ( GlobalCluster ) не была вызвана операция API FailoverGlobalCluster.

Статус -> (строка)

Текущее состояние глобальной базы данных Aurora ( GlobalCluster ). Возможные значения:

• в ожидании — служба получила запрос на отработку отказа глобальной базы данных Aurora ( GlobalCluster ). Первичный кластер БД GlobalCluster и указанный вторичный кластер БД проверяются перед запуском процесса отработки отказа.
• отработка отказа — этот статус охватывает ряд внутренних операций Aurora, выполняемых в процессе отработки отказа, таких как понижение роли основного кластера БД Aurora, повышение роли вторичной БД Aurora и синхронизация реплик.
• отмена — запрос на отработку отказа глобальной базы данных Aurora ( GlobalCluster ) был отменен, и основной кластер базы данных Aurora и выбранный вторичный кластер базы данных Aurora возвращаются в прежнее состояние.

FromDbClusterArn -> (строка)

Имя ресурса Amazon (ARN) кластера БД Aurora, который в настоящее время понижается и который связан с этим состоянием.

ToDbClusterArn -> (строка)

Имя ресурса Amazon (ARN) кластера БД Aurora, который в настоящее время продвигается и связан с этим состоянием.

Подключение Looker к вашей базе данных

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

Создание нового подключения к базе данных

Выберите Connections в разделе Database на панели Admin . На На странице Connections нажмите кнопку Add Connection . Looker отображает страницу Connection Settings .

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

Дополнительные сведения о применении атрибутов пользователя к параметрам подключения см. в разделе «Подключения» документа Атрибуты пользователя 9.Страница документации 0020.

Имя

Имя соединения, которое вы хотите указать. Вы не должны использовать имя каких-либо папок. Это значение не обязательно должно соответствовать чему-либо в вашей базе данных; это просто ярлык, который вы назначаете. Вы будете использовать его в параметре соединения вашей модели LookML.

Диалект

Диалект SQL, соответствующий вашему соединению. Важно выбрать правильное значение, чтобы вам были представлены правильные параметры подключения и чтобы Looker мог правильно преобразовать ваш LookML в SQL.

SSH-сервер

Параметр SSH Server доступен, если экземпляр развернут в инфраструктуре Kubernetes и только если включена возможность добавления информации о конфигурации сервера SSH в ваш экземпляр Looker. Если эта опция не включена в вашем экземпляре Looker, но вы хотите ее включить, обратитесь к менеджеру своего аккаунта Looker или отправьте запрос в службу поддержки в Справочном центре Looker.

Сервер SSH автоматически выбирает для вас порт localhost, и в настоящее время указать порт localhost невозможно. Если вам нужно создать SSH-соединение, требующее указания порта локального хоста, обратитесь к своему менеджеру по работе с учетными записями Looker или отправьте запрос в службу поддержки в Справочном центре Looker.

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

Местный порт

Параметр Local Port доступен, только если включен параметр SSH Server .

По умолчанию Looker автоматически выбирает доступный локальный порт для туннеля SSH. Чтобы вручную выбрать локальный порт, выберите Ввод вручную и введите номер порта в поле 9.0019 Поле «Пользовательский локальный порт ». Убедитесь, что локальный порт доступен на вашем экземпляре.

Удаленный хост: порт

Имя хоста вашей базы данных и порт, который Looker должен использовать для подключения к хосту вашей базы данных.

Если вы работали с аналитиком Looker для настройки туннеля SSH к вашей базе данных, в поле Host введите "localhost" , а в поле Port введите номер порта, который перенаправляет на вашу базу данных, которую вы Аналитик Looker должен был предоставить.

Если вы применяете атрибут пользователя к полю Хост , атрибуту пользователя не может быть присвоен уровень доступа пользователя, равный Редактируемый .

Если вы настроили туннель SSH для подключения к базе данных, вы не можете применить атрибут пользователя к полю Удаленный хост: порт .

База данных

Имя базы данных на вашем хосте. Например, у вас может быть имя хоста my-instance.us-east-1.redshift.amazonaws.com , на котором есть база данных с именем 9.1131 sales_info . Вы должны ввести sales_info в это поле. Если у вас есть несколько баз данных на одном хосте, вам может потребоваться создать несколько подключений для их использования (за исключением MySQL, в котором слово база данных означает что-то немного другое, чем в большинстве диалектов SQL).

Использовать OAuth

Для подключений Snowflake и Google BigQuery можно использовать OAuth. Это означает, что ваши пользователи должны авторизоваться в Snowflake или Google соответственно, чтобы выдавать запросы из Looker.

При выборе Использовать OAuth вы увидите поля Идентификатор клиента OAuth и Секрет клиента OAuth :

Эти значения генерируются из базы данных Snowflake или из Google. См. страницу документации, описывающую конфигурацию OAuth Snowflake или конфигурацию OAuth Google BigQuery для получения полной информации о процедуре.

Имя пользователя

Имя пользователя, которое Looker должен использовать для подключения к вашей базе данных. Вы должны заранее настроить пользователя в соответствии с нашими инструкциями по настройке базы данных.

Пароль

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

Электронная почта учетной записи службы

Электронная почта учетной записи службы, которая используется для доступа к вашей базе данных. Учетная запись службы управляется через вашу базу данных. См. документацию Looker по подключению к Google BigQuery для получения информации о том, как подключиться к BigQuery с помощью сервисного аккаунта.

Файл JSON/P12 учетной записи службы

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

Схема

Схема по умолчанию, которую использует Looker, если схема не указана. Это применимо, когда вы используете SQL Runner, во время создания проекта LookML и когда вы запрашиваете таблицы.

Постоянные производные таблицы

Установите этот флажок, чтобы включить постоянные производные таблицы. Это показывает дополнительные поля PDT и столбец PDT Overrides . Looker отображает эту опцию, только если диалект базы данных поддерживает использование PDT.

Обратите внимание на следующее в отношении PDT:

• PDT не поддерживаются для подключений Snowflake, использующих OAuth.
• Отключение PDT для соединения не отключает группы данных, связанные с вашими PDT. Даже если вы отключите PDT, существующие группы данных все равно будут выполнять свои 9 функций.1131 sql_trigger запросов к базе данных. Если вы хотите, чтобы группа данных не выполняла свой запрос sql_trigger к вашей базе данных, вы должны удалить или закомментировать параметр группы данных из своего проекта LookML или обновить параметр PDT и График обслуживания группы данных для соединения. так что Looker проверяет PDT и группы данных очень редко или никогда.
• Для соединений Snowflake Looker устанавливает значение для AUTOCOMMIT на TRUE (значение Snowflake по умолчанию). AUTOCOMMIT требуется для команд SQL, которые Looker запускает для поддержания своей системы регистрации PDT.

Временная база данных

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

Каждое соединение должно иметь собственную временную базу данных или схему ; они не могут быть разделены между соединениями.

Max PDT Builder Connections

Параметр Max PDT Builder Connections позволяет указать, сколько одновременных построений таблиц регенератор Looker может инициировать при подключении к вашей базе данных. Параметр Max PDT Builder Connections применяется только к тем типам таблиц, для которых регенератор Looker инициирует перестроения:

• Триггер-сохраняемые таблицы (постоянные производные таблицы и сводные таблицы, использующие стратегию сохранения datagroup_trigger или sql_trigger_value ).
• Сохраняемые таблицы, использующие стратегию сохраняемости persist_for , но только в том случае, если таблица persist_for является частью каскада производных таблиц, где от нее зависит таблица, использующая стратегию сохраняемости datagroup_trigger или sql_trigger_value . В этом случае регенератор Looker перестроит persist_for , так как эта таблица необходима для перестроения другой таблицы в каскаде. В противном случае регенератор не инициирует сборки для persist_for таблиц.

Параметр Max PDT Builder Connections по умолчанию равен 1 , но может быть установлен до 10 . Однако это значение не может быть выше, чем значение, установленное в поле Max Connections или в пределе запроса пользователя , установленном в параметрах запуска Looker.

Тщательно устанавливайте это значение. Если значение слишком велико, вы можете перегрузить базу данных. Если значение низкое, то длительные PDT или сводные таблицы могут задержать создание других постоянных таблиц или замедлить выполнение других запросов в соединении. Базы данных, поддерживающие мультитенантность, такие как BigQuery, Snowflake и Redshift, могут быть более производительными при обработке параллельных построений запросов.

Если вы хотите увеличить параметр Max PDT Builder Connections , рекомендуется увеличить его на 1. Если происходит какое-либо неожиданное поведение, верните значение по умолчанию 1 . В противном случае, если производительность запросов не пострадает, вы можете продолжать постепенно повышать ее на 1 и проверять производительность при каждом приращении перед дальнейшим увеличением параметра.

Обратите внимание на следующее в отношении параметра Max PDT Builder Connections :

• Параметр Max PDT Builder Connections применяется только к соединениям, необходимым для перестроения таблиц, а не к соединениям, необходимым для проверки триггеров. Проверка триггера — это запрос, проверяющий, сработала ли стратегия сохраняемости таблицы; поскольку эти запросы проверки триггеров всегда выполняются последовательно, Параметр Max PDT Builder Connections не применяется.
• В кластерном экземпляре Looker регенератор работает только на основном узле. Параметр Max PDT Builder Connections применяется только к основному узлу и, следовательно, устанавливает ограничение для всего кластера.
• Параметр Max PDT Builder Connections не применяется к следующим типам таблиц. Эти типы таблиц строятся последовательно:
  • Таблицы сохранялись через параметр persist_for (если от таблицы не зависят таблицы, использующие стратегии datagroup_trigger или sql_trigger_value ).
  • Таблицы в режиме разработки.
  • Таблицы, перестроенные с помощью параметра Rebuild Derived Tables & Run .
  • Таблицы, в которых одна зависит от другой в каскаде зависимостей. Таблица не может создаваться одновременно с таблицей, от которой она зависит. Например, если table_B зависит от table_A , то table_A должен завершить перестроение, прежде чем table_B сможет начать перестроение.

Всегда повторять неудачные сборки PDT

Параметр Всегда повторять неудачные сборки PDT настраивает, как регенератор Looker пытается перестроить поддерживаемые триггером сохраненные таблицы, которые не удалось выполнить в предыдущем цикле регенератора. Регенератор Looker — это процесс, который перестраивает триггерные персистентные таблицы (PDT и сводные таблицы) в соответствии с интервалом, настроенным в Настройка соединения PDT и графика обслуживания группы данных . Если параметр Always Retry Failed PDT Builds включен, регенератор Looker попытается восстановить PDT, который не удалось выполнить в предыдущем цикле регенератора, даже если условие срабатывания PDT не выполняется. Если этот параметр отключен, регенератор Looker попытается восстановить ранее неудавшийся PDT, только если будет выполнено условие срабатывания PDT. Всегда повторять неудачные сборки PDT отключено по умолчанию.

Дополнительную информацию о регенераторе Looker см. на странице документации Производные таблицы в Looker.

Enable PDT API Control

Параметр Enable PDT API Control определяет, могут ли вызовы API start_pdt_build , check_pdt_build и stop_pdt_build использоваться для этого соединения API. Если этот параметр отключен, эти вызовы API будут завершаться ошибкой, если они будут ссылаться на PDT в этом соединении. Включить управление API PDT по умолчанию отключен.

Дополнительные параметры

При необходимости здесь можно указать дополнительные параметры подключения к базе данных Java (JDBC) для ваших запросов.

Чтобы сослаться на атрибут пользователя в параметре JDBC, используйте синтаксис шаблонов Liquid: _user_attributes['name_of_attribute'] . Например:

 my_jdbc_param={{ _user_attributes['name_of_attribute'] }}
 

Вот как это может выглядеть в поле Дополнительные параметры в Looker:

Дополнительные параметры JDBC не тестируются Looker и могут привести к непредвиденному поведению.

График обслуживания PDT и групп данных

Регенератор Looker проверяет группы данных и постоянные таблицы (как сводные, так и постоянные производные таблицы), основанные на sql_trigger_value . На основе этих проверок регенератор Looker перестраивает или удаляет сохраненные таблицы из начальной схемы вашей базы данных.

9Значение 0019 PDT и расписания обслуживания группы данных задает интервал cron для регенератора Looker. Регенератор Looker инициирует цикл регенератора для проверки групп данных и сохраненных таблиц в интервале cron . Если цикл регенератора Looker все еще выполняется в следующем интервале cron , регенератор Looker завершит текущий цикл регенератора, а затем дождется следующего интервала cron , чтобы начать следующий цикл регенератора.

Настройка PDT и расписания обслуживания группы данных принимает выражение cron . Значение по умолчанию — */5 * * * * , что означает, что цикл регенератора Looker инициирует цикл с пятиминутным интервалом, если предыдущий цикл регенератора завершился. Если предыдущий цикл регенератора не завершился, регенератор Looker запустится в течение следующих пяти минут после завершения его цикла.

По умолчанию пять минут также являются наиболее частым интервалом, поддерживаемым для График техобслуживания PDT и группы данных . Looker не применяет максимальный интервал для PDT и графика обслуживания группы данных , что означает, что вы можете увеличить интервал между циклами регенератора Looker до тех пор, пока это может быть указано выражением cron . Имейте в виду, что более длительные циклы регенератора Looker могут отрицательно сказаться на свежести данных в вашем кэше и сохраняемых таблицах.

После того, как регенератор Looker завершит все проверки и перестроит PDT в цикле, он будет ждать следующих cron интервал для запуска следующего цикла. Если у вас есть длительные сборки PDT, у вас могут быть длительные периоды между циклами регенератора Looker. На время, необходимое для перестроения таблиц, могут влиять и другие факторы, как описано в разделе Важные замечания по реализации сохраняемых таблиц на странице Производные таблицы в Looker.

Если ваша база данных не работает круглосуточно и без выходных, вы можете ограничить проверки временем, когда база данных работает. Вот некоторые дополнительные выражения cron :

Несколько моментов, на которые следует обратить внимание при создании выражения cron :

• Looker использует parse-cron v0. 1.3, который не поддерживает ? в выражениях cron .
• Выражение cron использует часовой пояс приложения Looker для определения времени выполнения проверок.
• Если PDT не строятся, сбросьте строку cron до значения по умолчанию 9.1131 */5 * * * * .

Ниже приведены некоторые ресурсы, которые помогут создать строки cron :

• https://crontab.guru — помощь в редактировании и тестировании строк cron .
• http://www.crontab-generator.org — выберите настройки времени, и генератор создаст соответствующую строку cron .

SSL

Выберите, хотите ли вы использовать SSL-шифрование для защиты данных при их передаче между Looker и вашей базой данных. SSL — это только один вариант, который можно использовать для защиты ваших данных; другие безопасные параметры описаны на странице документации Включение безопасного доступа к базе данных.

Проверка SSL-сертификата

Выберите, требуется ли проверка сертификата SSL, используемого соединением. Если требуется проверка, центр сертификации SSL (ЦС), подписавший сертификат SSL, должен быть из списка доверенных источников клиента. Если ЦС не является доверенным источником, соединение с базой данных не устанавливается.

Если этот флажок не установлен, шифрование SSL по-прежнему используется в соединении, но проверка соединения SSL не требуется, поэтому соединение может быть установлено, когда ЦС отсутствует в списке доверенных источников клиента.

Max Connections

Здесь вы можете установить максимальное количество подключений, которые Looker может установить с вашей базой данных. По большей части вы устанавливаете количество одновременных запросов, которые Looker может выполнять к вашей базе данных. Looker также резервирует до трех подключений для уничтожения запросов. Если пул соединений очень мал, Looker будет резервировать меньше соединений.

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

Значение по умолчанию (которое зависит от вашего диалекта SQL) обычно является разумной отправной точкой. Большинство баз данных также имеют собственные настройки максимального количества принимаемых соединений. Если ваша конфигурация базы данных ограничивает количество подключений, убедитесь, что значение параметра Max Connections равно или ниже ограничения вашей базы данных.

Тайм-аут пула подключений

Если ваши пользователи запрашивают больше подключений, чем указано в параметре Max Connections , запросы будут ожидать завершения других, прежде чем они будут выполнены. Здесь настраивается максимальное время ожидания запроса. Вы должны установить это значение осторожно. Если оно слишком низкое, пользователи могут обнаружить, что их запросы отменяются, потому что не хватает времени для завершения запросов других пользователей. Если он слишком высок, может накопиться большое количество запросов, что заставит пользователей ждать очень долго. Значение по умолчанию обычно является разумной отправной точкой.

Оценка стоимости

Флажок Оценка стоимости применяется только к следующим соединениям с базой данных:

• Snowflake
• Амазонка Красное смещение
• Амазонка Аврора
• PostgreSQL, Cloud SQL для PostgreSQL и Microsoft Azure PostgreSQL

Флажок Cost Estimate включает следующие функции соединения:

• Оценки затрат для запросов Explore
• Оценка стоимости запросов SQL Runner
• Оценка экономии вычислений для совокупных запросов осведомленности

Соединения

BigQuery и MySQL также поддерживают функцию Cost Estimate ; однако, поскольку эта функция всегда включена, флажок Cost Estimate для подключений BigQuery и MySQL отсутствует.

Дополнительную информацию см. на странице документации «Изучение данных в Looker».

Предварительный кэш SQL Runner

В SQL Runner вся табличная информация предварительно загружается, как только вы выбираете соединение и схему. Это позволяет SQL Runner быстро отображать столбцы таблицы, как только вы щелкаете имя таблицы. Однако для подключений и схем со многими таблицами или с очень большими таблицами вы можете не захотеть, чтобы SQL Runner предварительно загружал всю информацию.

Если вы предпочитаете, чтобы SQL Runner загружал информацию таблицы только тогда, когда таблица выбрана, вы можете отменить выбор параметра SQL Runner Precache , чтобы отключить предварительную загрузку SQL Runner для соединения.

Получение информационной схемы для записи SQL

Для некоторых функций записи SQL, таких как совокупная осведомленность, Looker использует информационную схему вашей базы данных для оптимизации записи SQL. Если информационная схема не кэшируется, Looker может время от времени блокировать запись SQL в базу данных, чтобы получить информационную схему. Для диалектов, использующих распределенную файловую систему Hadoop (HDFS), получение информационной схемы может занять достаточно много времени, что существенно повлияет на производительность ваших запросов Looker. Если вы знаете, что ваша информационная схема работает медленно, вы можете отключить Извлечь информационную схему для SQL Запись опции для вашего соединения. Отключение этой функции предотвратит некоторую оптимизацию SQL Looker для определенных функций, поэтому вам следует включить параметр Fetch Information Schema For SQL Writing , если только вы не знаете, что информационная схема вашего соединения особенно медленная.

Параметр «Отключить контекстный комментарий » применяется только к соединениям BigQuery. Контекстные комментарии к подключениям Google BigQuery по умолчанию отключены, поскольку контекстные комментарии делают недействительной способность Google BigQuery кэшировать и могут негативно повлиять на производительность кэширования. Вы можете включить контекстные комментарии для подключения BigQuery, сняв флажок Параметр Отключить контекстный комментарий на странице Параметры подключения для подключения. Дополнительную информацию см. на странице документации Google BigQuery.

Часовой пояс базы данных

Часовой пояс, в котором ваша база данных хранит информацию о времени. Looker должен знать это, чтобы он мог преобразовывать значения времени для пользователей, упрощая понимание и использование данных, основанных на времени. Дополнительную информацию см. на странице документации «Использование настроек часового пояса».

Часовой пояс запроса

Параметр Запрос часового пояса виден только в том случае, если вы отключили Индивидуальные часовые пояса пользователя .

Когда Особые часовые пояса пользователя отключены, часовой пояс запроса — это часовой пояс, который отображается для ваших пользователей, когда они запрашивают данные на основе времени, и часовой пояс, в который Looker будет преобразовывать данные на основе времени из Часовой пояс базы данных .

Дополнительную информацию см. на странице документации по параметрам часового пояса.

Настройка отдельных учетных данных для входа в систему для процессов PDT

Примечание: Если вы включили параметр SSH-сервер , поля Удаленный хост: порт в столбце PDT Overrides нельзя будет редактировать.

Если ваша база данных поддерживает постоянные производные таблицы и вы установили флажок Постоянные производные таблицы в настройках соединения, Looker отобразит столбец PDT Overrides . В столбце PDT Overrides можно ввести отдельные параметры JDBC (хост, порт, база данных, имя пользователя, пароль, схема и дополнительные параметры), относящиеся к процессам PDT. Это может быть полезно по ряду причин:

• Создав отдельного пользователя базы данных для процессов PDT, вы сможете использовать PDT в своем проекте Looker, даже если вы назначите атрибуты пользователя своим учетным данным для входа в базу данных или используете OAuth для подключения к базе данных.
• Процессы PDT могут аутентифицироваться через отдельного пользователя базы данных, который имеет более высокий приоритет. Таким образом, база данных может отдавать приоритет заданиям PDT по сравнению с менее важными пользовательскими запросами.
• Доступ для записи может быть отозван для стандартного подключения к базе данных Looker и предоставлен только специальному пользователю, которого процессы PDT будут использовать для аутентификации. Это лучшая стратегия безопасности для большинства организаций.
• Для таких баз данных, как Snowflake, процессы PDT могут быть перенаправлены на более мощное оборудование, которое не используется остальными пользователями Looker. Таким образом, PDT могут создаваться быстро, не неся затрат на постоянное использование дорогостоящего оборудования.

Например, следующая конфигурация показывает соединение, в котором поля имени пользователя и пароля установлены в атрибуты пользователя. Таким образом, каждый пользователь может получить доступ к базе данных, используя свои индивидуальные учетные данные. Переопределение PDT 9Столбец 0020 создает отдельного пользователя ( pdt_user ) с собственным паролем. Учетная запись pdt_user будет использоваться для всех процессов PDT с уровнями доступа, соответствующими созданию и обновлению PDT:

Хотя столбец PDT Overrides позволяет изменить пользователя базы данных и другие свойства соединения, переопределение PDT должно считывать те же данные, что и соединение по умолчанию, и записывать данные в то же место. Looker не может читать данные из одного места и записывать их в другое.

Проверка параметров подключения

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

Если ваше подключение не проходит один или несколько тестов:

• Попробуйте выполнить некоторые шаги по устранению неполадок на странице документации по тестированию подключения к базе данных.
• Если вы используете Mongo версии 3.6 или более ранней версии в Atlas и у вас возникает сбой канала связи, см. страницу документации Mongo Connector.
• Чтобы получать сообщения об успешном подключении относительно временной схемы и PDT, вы должны разрешить эту функцию при настройке базы данных Looker. Инструкции для этого можно найти на странице документации Инструкции по настройке базы данных.

Для подключений к базам данных, использующих OAuth, таких как Snowflake и Google BigQuery, требуется вход пользователя. Если вы не вошли в свою учетную запись пользователя OAuth при тестировании одного из этих подключений, Looker покажет предупреждение с цифрой 9.0019 Войти ссылка. Нажмите на ссылку, чтобы ввести свои учетные данные OAuth или разрешить Looker доступ к информации вашей учетной записи OAuth.

Если проблема не устранена, обратитесь за помощью в службу поддержки Looker.

Тестировать как пользователь

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

Добавление подключения к базе данных

После настройки и проверки параметров подключения к базе данных нажмите Добавить подключение . Теперь ваше подключение к базе данных добавлено в список на странице Connections .

Следующие шаги

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

Базы данных | Документация Джанго | Джанго

Django официально поддерживает следующие базы данных:

• PostgreSQL
• МарияДБ
• MySQL
• Оракул
• SQLite

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

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

В этом файле описаны некоторые функции, которые могут иметь отношение к Django.
Применение. Он не предназначен для замены документации по конкретному серверу или
справочники.

Общие примечания

Постоянные соединения

Постоянные соединения позволяют избежать накладных расходов на повторное установление соединения с
базу данных в каждом запросе. Они находятся под контролем
CONN_MAX_AGE параметр, определяющий максимальное время жизни
связь. Его можно установить независимо для каждой базы данных.

Значение по умолчанию — 0 , сохраняя историческое поведение закрытия
подключение к базе данных в конце каждого запроса. Чтобы включить постоянный
подключений, задайте для CONN_MAX_AGE положительное целое число секунд. Для
неограниченное количество постоянных подключений, установите для него значение None .

Управление соединением

Django открывает соединение с базой данных при первом создании базы данных
запрос. Он сохраняет это соединение открытым и повторно использует его в последующих запросах.
Django закрывает соединение, как только оно превышает максимальный возраст, определенный
CONN_MAX_AGE или когда его больше нельзя использовать.

В частности, Django автоматически открывает соединение с базой данных всякий раз, когда она
нужен, а у него его еще нет — либо потому, что это первый
соединение, или потому что предыдущее соединение было закрыто.

В начале каждого запроса Django закрывает соединение, если оно
достиг своего максимального возраста. Если ваша база данных прерывает простаивающие соединения после
некоторое время вы должны установить CONN_MAX_AGE на меньшее значение, чтобы
Django не пытается использовать соединение, которое было разорвано
сервер базы данных. (Эта проблема может затрагивать только сайты с очень низким трафиком. )

В конце каждого запроса Django закрывает соединение, если оно достигло своего
максимальный возраст или если он находится в состоянии неисправимой ошибки. Если какая-либо база данных
при обработке запросов возникли ошибки, Django проверяет,
соединение все еще работает, и закрывает его, если это не так. Таким образом, ошибки базы данных
воздействовать не более чем на один запрос на каждый рабочий поток приложения; если
соединение становится непригодным для использования, следующий запрос получает новое соединение.

Настройка CONN_HEALTH_CHECKS 9от 0414 до True можно использовать для улучшения
надежность повторного использования соединения и предотвращение ошибок, когда соединение было
закрыт сервером базы данных, который теперь готов принимать и обслуживать новые
связи, напр. после перезапуска сервера базы данных. Проверка работоспособности выполняется
только один раз за запрос и только в том случае, если доступ к базе данных осуществляется во время
обработка запроса.

Изменено в Django 4.1:

Добавлен параметр CONN_HEALTH_CHECKS .

Предостережения

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

Иногда база данных не будет доступна для большинства ваших представлений, для
например, потому что это база данных внешней системы или благодаря кэшированию.
В таких случаях вы должны установить CONN_MAX_AGE на низкое значение или даже
0 , потому что нет смысла поддерживать соединение, которое маловероятно
для повторного использования. Это поможет сохранить количество одновременных подключений к
эта база данных маленькая.

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

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

Кодировка

Django предполагает, что все базы данных используют кодировку UTF-8. Использование других кодировок может
привести к неожиданному поведению, такому как ошибки «значение слишком длинное» из вашего
база данных для данных, которые действительны в Django. См. примечания к базе данных
ниже для получения информации о том, как правильно настроить базу данных.

Примечания к PostgreSQL

Django поддерживает PostgreSQL 11 и выше. psycopg2 2.8.4 или выше
требуется, хотя рекомендуется последняя версия.

Параметры подключения к PostgreSQL

Подробнее см. HOST .

Для подключения с использованием имени службы из файла службы подключения и
пароль из файла паролей, необходимо указать их в
ОПЦИИ часть конфигурации вашей базы данных в БАЗЫ ДАННЫХ :

settings. py

 БАЗЫ ДАННЫХ = {
    'по умолчанию': {
        'ДВИГАТЕЛЬ': 'django.db.backends.postgresql',
        'ПАРАМЕТРЫ': {
            «сервис»: «мой_сервис»,
            'файл-пароля': '.my_pgpass',
        },
    }
}
 

.pg_service.conf

 [мой_сервис]
хост = локальный
пользователь=ПОЛЬЗОВАТЕЛЬ
имя_базы_данных=ИМЯ
порт=5432
 

.my_pgpass

 локальный хост: 5432: ИМЯ: ПОЛЬЗОВАТЕЛЬ: ПАРОЛЬ
 

Изменено в Django 4.0:

Поддержка подключения по имени службы и указание файла пароля
был добавлен.

Предупреждение

Использование имени службы в целях тестирования не поддерживается. Этот
могут быть реализованы позже.

Оптимизация конфигурации PostgreSQL

Django нужны следующие параметры для подключения к базе данных:

• client_encoding : 'UTF8' ,
• default_transaction_isolation : «чтение зафиксировано» по умолчанию,
или значение, установленное в параметрах подключения (см. ниже),

• часовой пояс :

  • когда USE_TZ равно True , 'UTC' по умолчанию или
TIME_ZONE значение, установленное для соединения,
  • , когда USE_TZ равно False , значение глобального
TIME_ZONE настройка.

Если эти параметры уже имеют правильные значения, Django не установит их для
каждое новое соединение, что немного повышает производительность. Вы можете настроить
их напрямую в postgresql.conf или удобнее для каждой базы данных
пользователь с ALTER ROLE.

Django будет нормально работать и без этой оптимизации, но каждое новое соединение
выполнит несколько дополнительных запросов для установки этих параметров.

Уровень изоляции

Как и сам PostgreSQL, Django по умолчанию использует изоляцию READ COMMITTED
уровень. Если вам нужен более высокий уровень изоляции, такой как REPEATABLE READ или
SERIALIZABLE , установите его в части OPTIONS вашей базы данных
конфигурация в БАЗЫ ДАННЫХ :

 импорт psycopg2. extensions
БАЗЫ ДАННЫХ = {
    # ...
    'ПАРАМЕТРЫ': {
        'isolation_level': psycopg2.extensions.ISOLATION_LEVEL_SERIALIZABLE,
    },
}
 

Примечание

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

Индексы для

varchar и текст столбцов

При указании db_index=True в полях вашей модели Django обычно
выводит один оператор CREATE INDEX . Однако, если тип базы данных
для поля либо varchar , либо текст (например, используется CharField ,
FileField и TextField ), то Django создаст
дополнительный индекс, который использует соответствующий класс операторов PostgreSQL
для колонки. Дополнительный индекс необходим для правильного выполнения
поиски, которые используют оператор LIKE в своем SQL, как это делается с оператором
содержит , а начинается с типов поиска.

Операция миграции для добавления расширений

Если вам нужно добавить расширение PostgreSQL (например, hstore , postgis и т. д.)
используя миграцию, используйте
Операция CreateExtension .

Курсоры на стороне сервера

При использовании QuerySet.iterator() Django открывает серверную
курсор. По умолчанию PostgreSQL предполагает, что
будут получены только первые 10% результатов запросов курсора. Запрос
планировщик тратит меньше времени на планирование запроса и начинает возвращать результаты
быстрее, но это может снизить производительность, если более 10% результатов
получено. Предположения PostgreSQL о количестве строк, извлекаемых для
курсорный запрос управляется с помощью параметра cursor_tuple_fraction.

Пул транзакций и серверные курсоры

Использование пула соединений в режиме пула транзакций (например, PgBouncer)
требует отключения курсоров на стороне сервера для этого соединения.

Курсоры на стороне сервера являются локальными для соединения и остаются открытыми в конце соединения.
транзакция, когда AUTOCOMMIT равно True . А
последующая транзакция может попытаться получить больше результатов со стороны сервера
курсор. В режиме пула транзакций нет гарантии, что последующие
транзакции будут использовать одно и то же соединение. Если используется другое соединение,
возникает ошибка, когда транзакция ссылается на серверный курсор,
потому что курсоры на стороне сервера доступны только в том соединении, в котором они
были созданы.

Одним из решений является отключение серверных курсоров для соединения в
БАЗЫ ДАННЫХ , установив DISABLE_SERVER_SIDE_CURSORS на True .

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

Другой вариант — обернуть каждую QuerySet с использованием серверных курсоров в
блок atomic() , потому что он отключает автоматическую фиксацию
на время сделки. Таким образом, курсор на стороне сервера будет только
жить на время сделки.

Ручное указание значений автоматически увеличивающихся первичных ключей

Django использует столбцы идентификаторов PostgreSQL для хранения автоматически увеличивающихся первичных ключей
ключи. Столбец идентификаторов заполняется значениями из последовательности, которая сохраняет
отслеживать следующее доступное значение. Ручное присвоение значения
автоинкрементное поле не обновляет последовательность полей, что может позже
вызвать конфликт. Например:

 >>> из импорта пользователя django.contrib.auth.models
>>> User.objects.create(username='alice', pk=1)
<Пользователь: Алиса>
>>> # Последовательность не была обновлена; его следующее значение равно 1.
>>> User.objects.create(username='bob')
. ..
IntegrityError: повторяющееся значение ключа нарушает уникальное ограничение
"auth_user_pkey" ДЕТАЛЬ: Ключ (id)=(1) уже существует.
 

Если вам нужно указать такие значения, сбросьте последовательность впоследствии, чтобы избежать
повторное использование значения, которое уже находится в таблице. sqlsequencereset
Команда управления генерирует операторы SQL для этого.

Изменено в Django 4.1:

В более старых версиях PostgreSQL использовался тип данных SERIAL вместо
столбцы идентификации.

Тестовые шаблоны базы данных

Можно использовать параметр TEST['TEMPLATE'] , чтобы указать
шаблон (например, 'template0' ), из которого можно создать тестовую базу данных.

Ускорение выполнения теста с помощью неустойчивых настроек

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

Предупреждение

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

Примечания к MariaDB

Django поддерживает MariaDB 10.3 и выше.

Чтобы использовать MariaDB, используйте серверную часть MySQL, которая используется ими обоими. См.
Заметки MySQL для более подробной информации.

Заметки MySQL

Поддержка версий

Django поддерживает MySQL 5.7 и выше.

Функция Django inspectdb использует базу данных information_schema , которая
содержит подробные данные обо всех схемах базы данных.

Django ожидает, что база данных будет поддерживать Unicode (кодировку UTF-8) и делегирует
это задача обеспечения транзакций и ссылочной целостности. Это важно
знать о том факте, что два последних на самом деле не соблюдаются
MySQL при использовании механизма хранения MyISAM см. следующий раздел.

Механизмы хранения

MySQL имеет несколько механизмов хранения. Вы можете изменить механизм хранения по умолчанию
в конфигурации сервера.

Механизм хранения MySQL по умолчанию — InnoDB. Этот движок полностью транзакционный
и поддерживает ссылки на внешние ключи. Это рекомендуемый выбор. Однако
Счетчик автоинкремента InnoDB теряется при перезапуске MySQL, потому что он не
запомните значение AUTO_INCREMENT , вместо этого воссоздайте его как «max(id)+1».
Это может привести к непреднамеренному повторному использованию АвтоПоле
ценности.

Основные недостатки MyISAM в том, что он не поддерживает транзакции или
применять ограничения внешнего ключа.

Драйверы API базы данных MySQL

MySQL имеет пару драйверов, которые реализуют API базы данных Python, описанный в
PEP 249 :

• mysqlclient — это родной драйвер. Это рекомендуемый выбор .
• MySQL Connector/Python — это чистый драйвер Python от Oracle, который не
требуется клиентская библиотека MySQL или любые модули Python, выходящие за рамки стандарта
библиотека.

Эти драйверы потокобезопасны и обеспечивают пул соединений.

Помимо драйвера API БД, Django требуется адаптер для доступа к базе данных
драйверы из своего ORM. Django предоставляет адаптер для mysqlclient, в то время как MySQL
Connector/Python включает в себя собственный.

mysqlclient

Для Django требуется mysqlclient 1.4.0 или более поздней версии.

MySQL Connector/Python

MySQL Connector/Python доступен на странице загрузки.
Адаптер Django доступен в версиях 1.1.X и выше. Это может не
поддерживать самые последние выпуски Django.

Определения часовых поясов

Если вы планируете использовать поддержку часовых поясов Django,
используйте mysql_tzinfo_to_sql для загрузки таблиц часовых поясов в базу данных MySQL.
Это нужно сделать только один раз для вашего сервера MySQL, а не для каждой базы данных.

Создание базы данных

Вы можете создать базу данных с помощью инструментов командной строки и этого SQL:

 CREATE DATABASE  CHARACTER SET utf8;
 

Это гарантирует, что все таблицы и столбцы будут использовать кодировку UTF-8 по умолчанию.

Параметры сопоставления

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

Сопоставление также можно задать на уровне всей базы данных и для каждой таблицы. Это
подробно описаны в документации MySQL. В таких случаях вы должны
установить параметры сортировки, напрямую манипулируя настройками базы данных или таблицами.
Django не предоставляет API для их изменения.

По умолчанию для базы данных UTF-8 MySQL будет использовать
utf8_general_ci сопоставление. Это приводит к равенству всех строк
сравнения выполняются без учета регистра . То есть "Фред" и
"freD" считаются равными на уровне базы данных. Если у вас есть уникальный
ограничение на поле, было бы незаконно пытаться вставить "aa" и
"AA" в тот же столбец, так как они сравниваются как равные (и, следовательно,
неуникальный) с параметрами сортировки по умолчанию. Если вы хотите сравнения с учетом регистра
в определенном столбце или таблице измените столбец или таблицу, чтобы использовать
utf8_bin сопоставление.

Обратите внимание, что в соответствии с наборами символов MySQL Unicode сравнения для
сопоставление utf8_general_ci быстрее, но немного менее правильно, чем
сравнения для utf8_unicode_ci . Если это приемлемо для вашего приложения,
вы должны использовать utf8_general_ci , потому что это быстрее. Если это неприемлемо
(например, если вам нужен порядок немецкого словаря), используйте utf8_unicode_ci
потому что это точнее.

Предупреждение

Наборы форм проверяют уникальные поля с учетом регистра. Таким образом, когда
с использованием сортировки без учета регистра, набора форм с уникальными значениями полей, которые
отличаются только регистром, пройдут проверку, но при вызове save()
Будет вызвана ошибка IntegrityError .

Подключение к базе данных

См. документацию по настройкам.

Параметры соединения используются в следующем порядке:

1. ОПЦИИ .
2. ИМЯ , ПОЛЬЗОВАТЕЛЬ , ПАРОЛЬ , ХОСТ ,
ПОРТ
3. файлов опций MySQL.

Другими словами, если вы установите имя базы данных в OPTIONS ,
это будет иметь приоритет над ИМЯ , которое переопределит
что-нибудь в файле опций MySQL.

Вот пример конфигурации, в которой используется файл параметров MySQL:

 # settings.py
БАЗЫ ДАННЫХ = {
    'по умолчанию': {
        «ДВИГАТЕЛЬ»: «django.db.backends.mysql»,
        'ПАРАМЕТРЫ': {
            'read_default_file': '/path/to/my.cnf',
        },
    }
}
# my.cnf
[клиент]
база данных = ИМЯ
пользователь = ПОЛЬЗОВАТЕЛЬ
пароль = ПАРОЛЬ
набор символов по умолчанию = utf8
 

Могут быть полезны несколько других параметров подключения MySQLdb, например ssl ,
init_command и sql_mode .

Параметр

sql_mode

Начиная с MySQL 5.7 значение по умолчанию параметра sql_mode содержит
STRICT_TRANS_TABLES . Эта опция превращает предупреждения в ошибки, когда данные
усекаются при вставке, поэтому Django настоятельно рекомендует активировать
строгий режим для MySQL для предотвращения потери данных (либо STRICT_TRANS_TABLES
или STRICT_ALL_TABLES ).

Если вам нужно настроить режим SQL, вы можете установить переменную sql_mode
как и другие параметры MySQL: либо в файле конфигурации, либо с записью
'init_command': "SET sql_mode='STRICT_TRANS_TABLES'" в
ОПЦИИ часть конфигурации вашей базы данных в БАЗЫ ДАННЫХ .

Уровень изоляции

При одновременной загрузке транзакции базы данных из разных сеансов
(скажем, отдельные потоки, обрабатывающие разные запросы) могут взаимодействовать с каждым
другой. На эти взаимодействия влияет изоляция транзакций каждого сеанса.
уровень. Вы можете установить уровень изоляции соединения с
'isolation_level' запись в части OPTIONS вашей базы данных
конфигурация в БАЗЫ ДАННЫХ . Допустимые значения для
эта запись представляет собой четыре стандартных уровня изоляции:

• «чтение незафиксированных»
• «чтение зафиксировано»
• 'повторяемое чтение'
• «сериализуемый»

или Нет для использования настроенного уровня изоляции сервера. Тем не менее, Джанго
лучше всего работает с и по умолчанию для чтения зафиксировано, а не по умолчанию MySQL,
повторяемое чтение. Потеря данных возможна при повторяющемся чтении. В частности,
вы можете увидеть случаи, когда get_or_create()
вызовет IntegrityError , но объект не появится в
последующий вызов get() .

Создание таблиц

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

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

• После создания таблиц выполните оператор ALTER TABLE , чтобы
преобразовать таблицу в новый механизм хранения (например, InnoDB):

   ALTER TABLE <имя_таблицы> ENGINE=INNODB;
   

  Это может быть утомительно, если у вас много таблиц.

• Другой вариант — использовать параметр init_command для MySQLdb до
создание ваших таблиц:

   'ОПЦИИ': {
     'init_command': 'SET default_storage_engine=INNODB',
  }
   

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

Имена таблиц

Даже в последних версиях MySQL существуют известные проблемы, которые могут привести к
случай изменения имени таблицы при выполнении определенных операторов SQL
при определенных условиях. Рекомендуется использовать таблицу нижнего регистра
имена, если это возможно, чтобы избежать проблем, которые могут возникнуть из-за такого поведения.
Django использует имена таблиц в нижнем регистре, когда автоматически генерирует имена таблиц из
модели, так что это в основном соображение, если вы переопределяете имя таблицы
через параметр db_table .

Точки сохранения

Как Django ORM, так и MySQL (при использовании механизма хранения InnoDB) поддерживают точки сохранения базы данных.

Если вы используете механизм хранения MyISAM, имейте в виду, что вы
получать ошибки, сгенерированные базой данных, если вы пытаетесь использовать связанную с точкой сохранения
методы API транзакций. Причина
для этого является то, что обнаружение механизма хранения базы данных/таблицы MySQL является
дорогая операция, поэтому было решено, что динамическое преобразование не стоит
эти методы в no-op основаны на результатах такого обнаружения.

Примечания к определенным полям

Символьные поля

Любые поля, сохраненные с типами столбцов VARCHAR , могут иметь свои
max_length ограничено 255 символами, если вы используете unique=True
для поля. Это влияет на CharField ,
Слагфилд . См. документацию MySQL для получения дополнительной информации.
подробности.

TextField ограничения

MySQL может индексировать только первые N символов BLOB или ТЕКСТ столбец. С
TextField не имеет определенной длины, вы не можете пометить его как
уникальный=Истинно . MySQL сообщит: «Столбец BLOB/TEXT ‘’ используется в ключе
спецификация без длины ключа».

Поддержка дробных секунд для полей Time и DateTime

MySQL может хранить дробные секунды при условии, что определение столбца
включает дробную индикацию (например, DATETIME(6) ).

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

 ALTER TABLE `your_table` MODIFY `your_datetime_column` DATETIME(6)
 

или с помощью операции RunSQL в
перенос данных.

TIMESTAMP столбцов

Если вы используете устаревшую базу данных, содержащую столбцов TIMESTAMP , вы должны
установите USE_TZ = False , чтобы избежать повреждения данных.
inspectdb сопоставляет эти столбцы с
DateTimeField и если вы включите поддержку часового пояса,
и MySQL, и Django попытаются преобразовать значения из UTC в местное время.

Блокировка строк с помощью

QuerySet.select_for_update()

MySQL и MariaDB не поддерживают некоторые параметры SELECT . .. FOR UPDATE
заявление. Если select_for_update() используется с неподдерживаемой опцией, то
возникает ошибка NotSupportedError .

При использовании select_for_update() в MySQL убедитесь, что вы фильтруете набор запросов
по крайней мере против набора полей, содержащихся в уникальных ограничениях, или только
против полей, покрытых индексами. В противном случае будет установлена ​​эксклюзивная блокировка записи.
приобретено за всю таблицу на время транзакции.

Автоматическое приведение типов может привести к неожиданным результатам

При выполнении запроса к строковому типу, но с целочисленным значением, MySQL
привести типы всех значений в таблице к целому числу перед выполнением
сравнение. Если ваша таблица содержит значения 'abc' , 'def' и вы
запрос для WHERE mycolumn=0 обе строки будут совпадать. Аналогично, ГДЕ mycolumn=1
будет соответствовать значению 'abc1' . Поэтому поля строкового типа, включенные в Django
всегда будет приводить значение к строке, прежде чем использовать его в запросе.

Если вы реализуете пользовательские поля модели, которые наследуются от
Поле напрямую, имеют приоритет
get_prep_value() или используйте
RawSQL ,
экстра() или
raw() , вы должны убедиться, что выполняете
соответствующее приведение типов.

Примечания к SQLite

Django поддерживает SQLite 3. 9.0 и более поздние версии.

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

Сопоставление подстрок и чувствительность к регистру

Для всех версий SQLite есть некоторое нелогичное поведение, когда
попытка сопоставить некоторые типы строк. Они срабатывают при использовании
iexact или содержит фильтров в наборах запросов. Поведение
разбивается на два случая:

1. Для сопоставления подстрок все совпадения выполняются без учета регистра. Это
фильтр, такой как filter(name__contains="aa") , будет соответствовать имени "Aabb" .

2. Для строк, содержащих символы вне диапазона ASCII, все точные строки
совпадения выполняются с учетом регистра, даже если параметры без учета регистра
передаются в запрос. Так что фильтр iexact будет вести себя точно
то же самое, что и фильтр , точный фильтр в этих случаях.

Некоторые возможные обходные пути описаны на сайте sqlite.org, но они
не используются бэкэндом SQLite по умолчанию в Django, так как включают их
было бы довольно трудно сделать надежно. Таким образом, Django выставляет значение по умолчанию
поведение SQLite, и вы должны знать об этом, когда делаете нечувствительные к регистру или
фильтрация подстрок.

Десятичная обработка

SQLite не имеет реального десятичного внутреннего типа. Десятичные значения внутренне
преобразуется в тип данных REAL (8-байтовое число с плавающей запятой IEEE), как
объясняется в документации по типам данных SQLite, поэтому они не поддерживают
правильно округленная десятичная арифметика с плавающей запятой.

Ошибки «База данных заблокирована»

SQLite предназначена для использования в качестве облегченной базы данных и поэтому не может поддерживать высокую
уровень параллелизма. OperationalError: база данных заблокирована ошибки указывают
что ваше приложение испытывает больше параллелизма, чем может sqlite
обрабатывать в конфигурации по умолчанию. Эта ошибка означает, что один поток или процесс
эксклюзивная блокировка соединения с базой данных и тайм-аут другого потока
ожидание блокировки будет снято.

Оболочка Python SQLite имеет
значение тайм-аута по умолчанию, которое определяет, как долго второй поток может
подождите блокировки до истечения времени ожидания и вызовет OperationalError: база данных
заблокирован 9ошибка 0414.

Если вы получаете эту ошибку, вы можете решить ее следующим образом:

• Переключение на другой сервер базы данных. В какой-то момент SQLite становится
слишком «легкий» для реальных приложений, и такого рода параллелизм
ошибки указывают на то, что вы достигли этой точки.

• Перепишите свой код, чтобы уменьшить параллелизм и гарантировать, что база данных
сделки недолговечны.

• Увеличьте значение тайм-аута по умолчанию, установив тайм-аут база данных
опция:

   'ОПЦИИ': {
      # ...
      'тайм-аут': 20,
      # ...
  }
   

  Это заставит SQLite немного подождать, прежде чем выдать сообщение «база данных заблокирована».
ошибки; это ничего не сделает для их решения.

QuerySet.select_for_update() не поддерживается

SQLite не поддерживает синтаксис SELECT ... FOR UPDATE . Звонок будет
не имеют никакого эффекта.

Стиль параметра «pyformat» в необработанных запросах не поддерживается

Для большинства бэкендов необработанные запросы ( Manager.raw() или cursor.execute() )
можно использовать стиль параметра «pyformat», где заполнители в запросе
задаются как '%(name)s' , а параметры передаются как словарь
а не список. SQLite не поддерживает это.

Изоляция при использовании

QuerySet.iterator()

В разделе Изоляция в SQLite при
изменение таблицы во время итерации по ней с использованием QuerySet. iterator() . Если
строка добавляется, изменяется или удаляется в цикле, то эта строка может или может
не отображаться или может появляться дважды в последующих результатах, полученных из
итератор. Ваш код должен обрабатывать это.

Включение расширения JSON1 в SQLite

Чтобы использовать JSONField в SQLite, необходимо включить
Расширение JSON1 для библиотеки Python sqlite3 . Если расширение
не включен в вашей установке, системная ошибка ( fields.E180 ) будет
поднятый.

Чтобы включить расширение JSON1, вы можете следовать инструкциям на
вики-страница.

Примечания Oracle

Django поддерживает версии Oracle Database Server 19c и выше. Версия 7.0
или более поздней версии требуется драйвер cx_Oracle Python.

Чтобы команда python manage.py migrate работала, ваш Oracle
пользователь базы данных должен иметь права на выполнение следующих команд:

• CREATE TABLE
• СОЗДАТЬ ПОСЛЕДОВАТЕЛЬНОСТЬ
• СОЗДАТЬ ПРОЦЕДУРУ
• СОЗДАТЬ ТРИГГЕР

Для запуска набора тестов проекта пользователю обычно нужны эти дополнительные
привилегии:

• СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ
• ИЗМЕНИТЬ ПОЛЬЗОВАТЕЛЯ
• УДАЛИТЬ ПОЛЬЗОВАТЕЛЯ
• СОЗДАТЬ ТАБЛИЧНОЕ ПРОСТРАНСТВО
• УДАЛИТЬ ТАБЛИЧНОЕ ПРОСТРАНСТВО
• СОЗДАТЬ СЕАНС ​​С ОПЦИЕЙ АДМИНИСТРАТОРА
• СОЗДАТЬ ТАБЛИЦУ С ОПЦИЕЙ АДМИНИСТРАТОРА
• СОЗДАТЬ ПОСЛЕДОВАТЕЛЬНОСТЬ С ОПЦИЕЙ АДМИНИСТРАТОРА
• СОЗДАТЬ ПРОЦЕДУРУ С ОПЦИЕЙ АДМИНИСТРАТОРА
• СОЗДАТЬ ТРИГГЕР С ОПЦИЕЙ АДМИНИСТРАТОРА

В то время как роль RESOURCE имеет требуемую CREATE TABLE ,
CREATE SEQUENCE , CREATE PROCEDURE и CREATE TRIGGER привилегии,
и пользователь, которому предоставлено РЕСУРС С ОПЦИЕЙ АДМИНИСТРИРОВАНИЯ , может предоставить РЕСУРС , например
пользователь не может предоставить индивидуальные привилегии (например, CREATE TABLE ), и, таким образом,
РЕСУРСОВ С ОПЦИЕЙ АДМИНИСТРИРОВАНИЯ обычно недостаточно для выполнения тестов.

Некоторые наборы тестов также создают представления или материализованные представления; чтобы запустить их,
пользователю также нужно СОЗДАТЬ ВИД С ОПЦИЕЙ АДМИНИСТРАТОРА и
CREATE MATERIALIZED VIEW WITH ADMIN OPTION привилегии. В частности, это
необходим для собственного набора тестов Django.

Все эти привилегии включены в роль DBA, которая подходит
для использования в базе данных частного разработчика.

Серверная часть базы данных Oracle использует SYS.DBMS_LOB и SYS.DBMS_RANDOM
пакеты, поэтому вашему пользователю потребуются права на выполнение. Это обычно
доступны для всех пользователей по умолчанию, но если это не так, вам нужно предоставить
разрешения вроде так:

 GRANT EXECUTE ON SYS.DBMS_LOB TO пользователю;
GRANT EXECUTE ON SYS.DBMS_RANDOM пользователю;
 

Подключение к базе данных

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

 БАЗЫ ДАННЫХ = {
    'по умолчанию': {
        «ДВИГАТЕЛЬ»: «django.db.backends.oracle»,
        «ИМЯ»: «xe»,
        «ПОЛЬЗОВАТЕЛЬ»: «a_user»,
        'ПАРОЛЬ': 'a_password',
        'ХОЗЯИН': '',
        'ПОРТ': '',
    }
}
 

В этом случае следует оставить как HOST , так и PORT пустыми.
Однако, если вы не используете файл tnsnames.ora или аналогичный метод именования
и хотите подключиться с помощью SID (в данном примере «xe»), то заполните оба
HOST и PORT вот так:

 DATABASES = {
    'по умолчанию': {
        «ДВИГАТЕЛЬ»: «django.db.backends.oracle»,
        «ИМЯ»: «xe»,
        «ПОЛЬЗОВАТЕЛЬ»: «a_user»,
        'ПАРОЛЬ': 'a_password',
        «ХОСТ»: «dbprod01ned.mycompany.com»,
        «ПОРТ»: «1540»,
    }
}
 

Вы должны указать оба HOST и PORT или оставить
оба как пустые строки. Django будет использовать другой дескриптор подключения в зависимости от
на том выборе.

Полный DSN и Easy Connect

Строка Full DSN или Easy Connect может использоваться в ИМЯ , если оба
HOST и PORT пусты. Этот формат необходим, когда
например, используя RAC или подключаемые базы данных без tnsnames.ora .

Пример строки Easy Connect:

 'ИМЯ': 'локальный: 1521/orclpdb1',
 

Пример полной строки DSN:

 'ИМЯ': (
    '(ОПИСАНИЕ=(АДРЕС=(ПРОТОКОЛ=TCP)(ХОСТ=localhost)(ПОРТ=1521))'
    '(CONNECT_DATA=(SERVICE_NAME=orclpdb1)))'
),
 

Threaded option

Если вы планируете запускать Django в многопоточной среде (например, Apache с использованием
модуль MPM по умолчанию в любой современной операционной системе), то вы должны установить
параметр threaded конфигурации вашей базы данных Oracle на Верно :

 'ОПЦИИ': {
    'резьбовой': правда,
},
 

Невыполнение этого требования может привести к сбоям и другим странным действиям.

INSERT … RETURNING INTO

По умолчанию серверная часть Oracle использует предложение RETURNING INTO для эффективного
получить значение AutoField при вставке новых строк. Это поведение
может привести к ошибке DatabaseError в некоторых необычных настройках, например, когда
вставка в удаленную таблицу или в представление с ВМЕСТО триггера.
Предложение RETURNING INTO можно отключить, установив параметр
use_returning_into параметр конфигурации базы данных False :

 'ОПЦИИ': {
    'use_returning_into': Ложь,
},
 

В этом случае серверная часть Oracle будет использовать отдельный запрос SELECT для
получить значений AutoField .

Проблемы с именами

Oracle ограничивает длину имени в 30 символов. Чтобы учесть это,
серверная часть обрезает идентификаторы базы данных, заменяя последние четыре
символы усеченного имени с повторяющимся хеш-значением MD5.
Кроме того, серверная часть преобразует идентификаторы базы данных в верхний регистр.

Для предотвращения этих преобразований (обычно это требуется только при работе с
с устаревшими базами данных или доступом к таблицам, принадлежащим другим пользователям), используйте
имя в кавычках в качестве значения для db_table :

 класс LegacyModel (models.Model):
    Мета класса:
        db_table = '"name_left_in_lowercase"'
класс ForeignModel (модели.Модель):
    Мета класса:
        db_table = '"OTHER_USER"."NAME_ONLY_SEEMS_OVER_30"'
 

Имена в кавычках также можно использовать с другими поддерживаемыми базами данных Django.
серверные части; однако, за исключением Oracle, кавычки не действуют.

При запуске migrate может возникнуть ошибка ORA-06552 , если
некоторые ключевые слова Oracle используются в качестве имени поля модели или
значение параметра db_column . Django цитирует все используемые идентификаторы
в запросах, чтобы предотвратить большинство таких проблем, но эта ошибка все еще может
возникают, когда тип данных Oracle используется в качестве имени столбца. В
в частности, позаботьтесь о том, чтобы не использовать имена , дата ,
метка времени , число или число с плавающей запятой в качестве имени поля.

NULL и пустые строки

Django обычно предпочитает использовать пустую строку ( '' ), а не
NULL , но Oracle обрабатывает оба значения одинаково. Чтобы обойти это,
Серверная часть Oracle игнорирует явный параметр null для полей, которые
иметь пустую строку в качестве возможного значения и генерирует DDL, как если бы
ноль=Истина . При выборке из базы данных предполагается, что
значение NULL в одном из этих полей действительно означает пустое
строка, и данные автоматически преобразуются, чтобы отразить это предположение.

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

Серверная часть Oracle хранит TextField как NCLOB столбцов. Оракул накладывает
некоторые ограничения на использование таких столбцов больших объектов в целом:

• столбцы больших объектов нельзя использовать в качестве первичных ключей.
• Столбцы больших объектов нельзя использовать в индексах.

Столбцы LOB

• нельзя использовать в списке SELECT DISTINCT . Это значит, что
попытка использовать метод QuerySet.distinct в модели, которая
включает Столбцы TextField приведут к ошибке ORA-00932 при
работать против Оракула. В качестве обходного пути используйте метод QuerySet.defer в
в сочетании с Different() для предотвращения столбцов TextField
включены в список SELECT DISTINCT .

Создание подклассов встроенных серверных частей базы данных

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

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

 мой сайт/
    . ..
    mydbengine/
        __init__.py
        base.py
 

Модуль base.py должен содержать класс с именем DatabaseWrapper , который
создает подклассы существующего движка из модуля django.db.backends . Вот
пример создания подкласса механизма PostgreSQL для изменения класса объектов
allow_group_by_selected_pks_on_model :

mysite/mydbengine/base.py

 из базы импорта django.db.backends.postgresql, функции
класс DatabaseFeatures (features.DatabaseFeatures):
    def allow_group_by_selected_pks_on_model (я, модель):
        вернуть Истина
класс DatabaseWrapper (base.DatabaseWrapper):
    features_class = Компоненты базы данных
 

Наконец, вы должны указать DATABASE-ENGINE в настройках .py
файл:

 БАЗЫ ДАННЫХ = {
    'по умолчанию': {
        «ДВИГАТЕЛЬ»: «mydbengine»,
        ...
    },
}
 

Текущий список ядер баз данных можно посмотреть в
джанго/дб/бэкенды.

Использование сторонней базы данных

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

• CockroachDB
• Жар-птица
• Google Cloud Spanner
• Microsoft SQL Server
• ТиБД
• ЮгабайтДБ

Версии Django и функции ORM, поддерживаемые этими неофициальными бэкэндами
значительно различаются. Запросы относительно конкретных возможностей этих
неофициальные серверные части вместе с любыми запросами в службу поддержки следует направлять на
каналы поддержки, предоставляемые каждым сторонним проектом.

Основы сеанса — Документация по SQLAlchemy 2.0

• Предыдущий:
Использование сеанса
• Следующий:
Государственное управление
• Вверх: Дом
• SQLAlchemy ORM
• Использование сеанса
• На этой странице:
• Основы сеанса
  • Что делает сеанс?
  • Основы использования сеанса
    • Открытие и закрытие сеанса
    • Создание блока начала/фиксации/отката
    • Использование создателя сеансов
    • Запрос
    • Добавление новых или существующих элементов
    • Удаление
    • Промывка
    • Получить по первичному ключу
    • Срок действия истекает / Обновление
    • UPDATE и DELETE с произвольным предложением WHERE
    • Автозапуск
      • Отключение автозапуска для предотвращения неявных транзакций
    • Совершение
    • Откат
    • Закрытие
  • Сеанс Часто задаваемые вопросы
    • Когда мне сделать создатель сеансов ?
    • Когда я создаю сеанс , когда его фиксирую и когда закрываю?
    • Является ли сеанс кэшем?
    • Как я могу получить сеанс для определенного объекта?
    • Является ли сеанс потокобезопасным?

Что делает сеанс?

В самом общем смысле сеанс устанавливает все
с базой данных и представляет собой «зону ожидания» для всех объектов,
вы загрузили или связались с ним в течение срока его службы. Он обеспечивает
интерфейс, где выполняются SELECT и другие запросы, которые будут возвращать и изменять
ORM-отображенные объекты. Сами объекты ORM поддерживаются внутри
Сессия внутри структуры, называемой идентификационной картой — данные
структура, которая поддерживает уникальные копии каждого объекта, где «уникальный» означает
«только один объект с определенным первичным ключом».

Сеанс начинается в основном в форме без сохранения состояния. Как только запросы
выпущенные или другие объекты сохраняются с ним, он запрашивает соединение
ресурс от Engine , который связан с
Session , а затем устанавливает транзакцию в этом соединении. Этот
сделка остается в силе до Сессия получает указание
зафиксировать или откатить транзакцию.

Объекты ORM, поддерживаемые сеансом , инструментированы
так что всякий раз, когда атрибут или коллекция изменяется в Python
программе генерируется событие изменения, которое записывается
Сессия . Всякий раз, когда база данных собирается быть запрошенной, или когда
транзакция вот-вот будет зафиксирована, сначала сеанс
сбрасывает все ожидающие изменения, хранящиеся в памяти, в базу данных. Это
известный как единица модели работы.

При использовании сеанса полезно учитывать сопоставленные объекты ORM.
которые он поддерживает как прокси-объектов для строк базы данных, которые являются локальными для
транзакция проводится сеансом . Для того, чтобы сохранить
состояние объектов как соответствующее тому, что на самом деле находится в базе данных, есть
множество событий, которые вызовут повторный доступ объектов к базе данных для
держи синхронизацию. Можно «отсоединять» объекты от
Сессия , и продолжать их использовать, хотя эта практика имеет свои
предостережения. Предполагается, что обычно вы повторно связываете отдельные объекты с
другой сеанс , когда вы хотите снова с ними работать, чтобы они
могут возобновить свою обычную задачу представления состояния базы данных.

Основы использования сеанса

Здесь представлены самые основные шаблоны использования Session .

Открытие и закрытие сеанса

Сеанс может быть создан самостоятельно или с использованием
сессионмейкер класс. Обычно передается один
Engine как источник подключения на переднем плане. Типичное использование
может выглядеть так:

 из импорта sqlalchemy create_engine
из сеанса импорта sqlalchemy.orm
# Движок, который Сессия будет использовать для подключения
# Ресурсы
engine = create_engine("postgresql+psycopg2://scott:tiger@localhost/")
# создать сессию и добавить объекты
с сеансом (движок) в качестве сеанса:
    session.add(некоторый_объект)
    session.add(some_other_object)
    сессия.commit() 

Выше сеанс создается с помощью механизма
связанный с конкретным URL-адресом базы данных. Затем он используется в Python
диспетчер контекста (например, с оператором: ), чтобы он автоматически
закрытый в конце блока; это эквивалентно
для вызова метода Session. close() .

Вызов Session.commit() является необязательным и требуется только в том случае, если
работа, которую мы проделали с Session , включает новые данные,
сохраняется в базе данных. Если бы мы выполняли только вызовы SELECT и не
нужно написать любые изменения, то звонок на Session.commit() будет
быть ненужным.

Примечание

Обратите внимание, что после Session.commit() вызывается либо явно, либо
при использовании менеджера контекста все объекты, связанные с
Сеансы просрочены, то есть их содержимое стирается до
быть перезагружены в рамках следующей транзакции. Если эти объекты вместо
отсоединены, они не будут функционировать до тех пор, пока не будут повторно связаны с
новый Session , если только Session.expire_on_commit
Параметр используется для отключения этого поведения. См.
раздел Совершение для более подробной информации.

Создание блока начала/фиксации/отката

Мы также можем заключить вызов Session. commit() и общий
«формирование» транзакции в менеджере контекста для тех случаев, когда
мы будем передавать данные в базу данных. Под «формированием» мы подразумеваем, что если все
операции завершатся успешно, будет вызван метод Session.commit() ,
но если возникнут какие-либо исключения, Метод Session.rollback()
будет вызван так, чтобы транзакция немедленно откатилась, прежде чем
распространение исключения наружу. В Python это наиболее фундаментально
выражается с использованием блока try:/except:/else: , например:

 # подробная версия того, что будет делать контекстный менеджер
с сеансом (движок) в качестве сеанса:
    сеанс.начать()
    пытаться:
        session.add(некоторый_объект)
        session.add(some_other_object)
    кроме:
        сессия.rollback()
        поднимать
    еще:
        сессия.commit() 

Проиллюстрированная выше длинная последовательность операций может быть
достигается более кратко, используя
Объект SessionTransaction , возвращенный функцией Session. begin()
метод, который предоставляет интерфейс менеджера контекста для той же последовательности
операций:

 # создать сеанс и добавить объекты
с сеансом (движок) в качестве сеанса:
    с session.begin():
        session.add(некоторый_объект)
        session.add(some_other_object)
    # внутренний контекст вызывает session.commit(), если не было исключений
# внешний контекст вызывает session.close() 

Более кратко, два контекста могут быть объединены:

 # создать сеанс и добавить объекты
с сеансом (движок) в качестве сеанса, session.begin():
    session.add(некоторый_объект)
    session.add(some_other_object)
# внутренний контекст вызывает session.commit(), если не было исключений
# внешний контекст вызывает session.close() 

Использование создателя сеансов

Целью sessionmaker является предоставление фабрики для
Сессия объектов с фиксированной конфигурацией. Как это типично
что приложение будет иметь Объект Engine в модуле
объем, создатель сеансов может предоставить фабрику для
Сессия Объекты против этого движка:

 из импорта sqlalchemy create_engine
из sqlalchemy. orm импортировать создатель сеансов
# Движок, который Сессия будет использовать для подключения
# ресурсы, обычно в области модуля
engine = create_engine("postgresql+psycopg2://scott:tiger@localhost/")
# sessionmaker(), также в той же области видимости, что и движок
Сессия = создатель сессий (движок)
# теперь мы можем построить Session() без необходимости передавать
# двигатель каждый раз
с Session() в качестве сеанса:
    session.add(некоторый_объект)
    session.add(some_other_object)
    сессия.commit()
# закрывает сессию 

Sessionmaker аналогичен Engine
как фабрика на уровне модулей для сеансов/соединений на уровне функций. Как таковой
у него также есть собственный метод sessionmaker.begin() , аналогичный
на Engine.begin() , который возвращает объект Session
а также поддерживает блок начала/фиксации/отката:

 из импорта sqlalchemy create_engine
из sqlalchemy.orm импортировать создатель сеансов
# Движок, который Сессия будет использовать для подключения
# Ресурсы
engine = create_engine("postgresql+psycopg2://scott:tiger@localhost/")
# sessionmaker(), также в той же области видимости, что и движок
Сессия = создатель сессий (движок)
# теперь мы можем создать Session() и включить begin()/commit()/rollback()
# однажды
с Session. begin() в качестве сеанса:
    session.add(некоторый_объект)
    session.add(some_other_object)
# фиксирует транзакцию, закрывает сессию 

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

Когда вы пишете свое приложение,
sessionmaker factory должен иметь ту же область действия, что и фабрика
Объект Engine , созданный с помощью create_engine() , который
обычно находится на уровне модуля или в глобальной области. Поскольку оба эти объекта
фабрики, они могут использоваться любым количеством функций и потоков
одновременно.

См. также

sessionmaker

Session

Запрос

Основным средством запроса является использование select()
конструкция для создания объекта Select , который затем выполняется для
вернуть результат, используя такие методы, как Session. execute() и
Session.scalars() . Затем результаты возвращаются в терминах
Результат объектов, включая подварианты, такие как
Скалярный результат .

Полное руководство по запросам SQLAlchemy ORM можно найти по адресу
Руководство по запросам ORM. Вот несколько кратких примеров:

 из выбора импорта sqlalchemy
из сеанса импорта sqlalchemy.orm
с сеансом (движок) в качестве сеанса:
    # запрос для объектов ``Пользователь``
    оператор = выберите (пользователь).filter_by (имя = "ed")
    # список объектов ``Пользователь``
    user_obj = session.scalars(оператор).all()
    # запрос для отдельных столбцов
    оператор = выберите (имя пользователя, полное имя пользователя)
    # список объектов Row
    строки = session.execute(оператор).all() 

Изменено в версии 2.0: запросы в стиле «2.0» теперь являются стандартными. Видеть
2.0 Миграция — ORM Использование для примечаний по миграции из серии 1.x.

См. также

Руководство по запросам ORM

Добавление новых или существующих элементов

Session. add() используется для размещения экземпляров в
сессия. Для временных (то есть совершенно новых) экземпляров это будет иметь эффект
INSERT, выполняемого для этих экземпляров при следующем сбросе. Для
экземпляры, которые являются постоянными (т. е. были загружены этим сеансом), они
уже есть и добавлять не нужно. Экземпляры, которые отсоединены
(т.е. были удалены из сеанса) могут быть повторно связаны с сеансом
используя этот метод:

 пользователь1 = пользователь (имя = "пользователь1")
пользователь2 = пользователь (имя = "пользователь2")
session.add(пользователь1)
сеанс. добавить (пользователь2)
session.commit() # запись изменений в базу данных 

Чтобы сразу добавить список элементов в сеанс, используйте
Session.add_all() :

 session.add_all([элемент1, элемент2, элемент3]) 

Операция Session.add() каскадирует вдоль
каскад сохранения-обновления . Подробнее смотрите в разделе
Каскады.

Удаление

Метод Session.delete() помещает экземпляр
в список объектов Сессии для пометки как удаленных:

 # отметить два объекта для удаления
session.delete(obj1)
session.delete(obj2)
# зафиксировать (или сбросить)
сессия.коммит() 

Session.delete() помечает объект для удаления, что
приводит к инструкции DELETE, выдаваемой для каждого затронутого первичного ключа.
Перед сбросом ожидающих удаления объекты, помеченные как «удалить», присутствуют.
в Session.deleted 9Коллекция 0414. После DELETE они
удаляются из сеанса , который становится постоянным после
сделка совершена.

Существуют различные важные поведения, связанные с
Операция Session.delete() , особенно в том, как отношения к
обрабатываются другие объекты и коллекции. Там больше информации о том, как
это работает в разделе Каскады, но в целом
правила такие:

• Строки, соответствующие сопоставленным объектам, связанным с удаленным
объект через отношения() директива нет
удалено по умолчанию . Если эти объекты имеют обратное ограничение внешнего ключа
к удаляемой строке эти столбцы устанавливаются в NULL. Это будет
вызвать нарушение ограничения, если столбцы не могут принимать значения NULL.

• Чтобы изменить «SET NULL» на DELETE строки связанного объекта, используйте
удалить каскад в отношении () .

• Строки, которые в таблицах связаны как таблицы «многие ко многим» через
ratio.secondary параметр, удалены во всех
случаи, когда объект, на который они ссылаются, удаляется.

• Когда связанные объекты включают ограничение внешнего ключа обратно в объект
удаляются, а связанные коллекции, к которым они принадлежат, не
в настоящее время загружен в память, единица работы выдаст SELECT для извлечения
все связанные строки, чтобы их значения первичного ключа можно было использовать для генерации либо
Операторы UPDATE или DELETE для этих связанных строк. Таким образом, ОРМ
без дальнейших инструкций выполнит функцию ON DELETE CASCADE,
даже если это настроено на Core Иностранный ключ ограничения
объекты.

• Можно использовать параметр ratio.passive_deletes
настроить это поведение и более естественно полагаться на «ON DELETE CASCADE»;
если установлено значение True, эта операция SELECT больше не будет выполняться, однако
строки, которые присутствуют локально, по-прежнему будут подвергаться явному SET NULL
или УДАЛИТЬ. Установка lation.passive_deletes на
строка "все" отключит обновление/удаление всех связанных объектов .

• Когда для объекта, отмеченного для удаления, происходит DELETE, объект
не удаляется автоматически из коллекций или ссылок на объекты, которые
обратитесь к нему. По истечении срока действия сеанса эти коллекции
может быть загружен снова, так что объект больше не присутствует. Однако,
предпочтительно вместо использования Session.delete() для
эти объекты, вместо этого объект должен быть удален из своей коллекции
а затем следует использовать delete-orphan, чтобы он
удален как вторичный эффект удаления этой коллекции. См.
раздел «Примечания к удалению — удаление объектов, на которые есть ссылки из коллекций и скалярных отношений», для примера.

См. также

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

delete-orphan — описывает «удалить потерянный каскад», который
помечает связанные объекты для удаления, когда они деассоциируются со своими
ведущий объект.

Примечания по удалению — удаление объектов, на которые имеются ссылки из коллекций и скалярных отношений — важные сведения о
Session.delete() as включает обновление отношений
в памяти.

Промывка

Когда сеанс используется по умолчанию
конфигурации, этап сброса почти всегда выполняется прозрачно.
В частности, сброс происходит до того, как кто-либо
Оператор SQL выдается в результате запроса или
вызов Session.execute() в стиле 2.0, а также внутри
Вызов Session. commit() до того, как транзакция
преданный идее. Это также происходит перед выдачей SAVEPOINT, когда
Session.begin_nested() используется.

Сброс сеанса может быть форсирован в любое время путем вызова
Session.flush() метод:

 сессия.flush() 

Сброс, который происходит автоматически в рамках определенных методов
известен как autoflush . Autoflush определяется как настраиваемый,
автоматический вызов сброса, который происходит в начале методов, включая:

• Session.execute() и другие методы выполнения SQL

• При вызове Query для отправки SQL в базу данных

• В методе Session.merge() перед запросом к базе данных

• При обновлении объектов

• Когда операции ленивой загрузки ORM выполняются для незагруженного объекта
атрибуты.

Также есть точки, в которых происходят сбросы безусловно ; эти
точки находятся в пределах ключевых транзакционных границ, которые включают:

• В процессе метода Session. commit()

• При вызове Session.begin_nested()

• При использовании метода Session.prepare() 2PC.

Поведение autoflush применительно к предыдущему списку элементов,
можно отключить, создав сеанс или
sessionmaker передает параметр Session.autoflush как
Ложь :

 Сеанс = создатель сеанса (autoflush = False) 

Кроме того, в потоке можно временно отключить автосброс.
использования сеанса с использованием
Менеджер контекста Session.no_autoflush :

 с mysession.no_autoflush:
    mysession.add(некоторый_объект)
    mysession.flush() 

Повторить: Процесс сброса всегда происходит при транзакции
такие методы, как Session.commit() и Session.begin_nested() являются
вызывается, независимо от каких-либо настроек «автоматической очистки», когда сеанс имеет
оставшиеся ожидающие изменения в процессе.

Поскольку сеанс вызывает SQL к базе данных только в контексте
транзакция DBAPI, все операции «сброса» сами по себе происходят только в
транзакция базы данных (при условии
уровень изоляции базы данных
транзакции) при условии, что DBAPI не находится в
режим автоматической фиксации на уровне драйвера. Это значит, что
предполагая, что соединение с базой данных обеспечивает атомарность в пределах его
транзакционные настройки, если какой-либо отдельный оператор DML внутри сброса не работает,
вся операция будет отменена.

Если при сбросе происходит сбой, чтобы продолжить использование этого
тот же Session , явный вызов Session.rollback()
требуется после сбоя сброса, даже если базовая транзакция будет иметь
уже был откатан (даже если драйвер базы данных технически находится в
режим автоматической фиксации на уровне драйвера). Это делается для того, чтобы общий шаблон вложения
постоянно поддерживаются так называемые «субтранзакции». Раздел часто задаваемых вопросов
«Транзакция этого сеанса была отменена из-за предыдущего исключения во время сброса». (или аналогичный) содержит более подробное описание этого
поведение.

См. также

«Транзакция этого сеанса была отменена из-за предыдущего исключения во время сброса». (или аналогичный) - дополнительная информация о том, почему
Session.rollback() должен вызываться при сбое сброса.

Получить по первичному ключу

Поскольку сеанс использует карту идентификации, которая ссылается
к текущим объектам в памяти по первичному ключу, Session.get()
метод предоставляется как средство поиска объектов по первичному ключу, сначала
просматривая текущую карту идентификации, а затем запрашивая базу данных
для непредставленных значений. Например, чтобы найти Объект пользователя с первичным ключом
идентификатор (5, ) :

 my_user = session.get(Пользователь, 5) 

Session. get() также включает формы вызова для составных первичных
ключевые значения, которые могут передаваться как кортежи или словари, а также
дополнительные параметры, которые позволяют использовать определенный загрузчик и параметры выполнения.
Полный список параметров см. в Session.get() .

См. также

Session.get()

Срок действия истекает / Обновление

Важное соображение, которое часто возникает при использовании
Сеанс — это сеанс работы с состоянием, которое присутствует на
объекты, которые были загружены из базы данных, с точки зрения их хранения
синхронизируется с текущим состоянием транзакции. SQLAlchemy
ORM основан на концепции карты идентичности, так что когда
объект «загружается» из SQL-запроса, будет уникальный Python
экземпляр объекта, поддерживаемый в соответствии с конкретным идентификатором базы данных.
Это означает, что если мы отправим два отдельных запроса, каждый для одной и той же строки, и получим
сопоставленный объект обратно, два запроса вернут один и тот же Python
объект:

 >>> u1 = session. scalars(select(User).where(User.id == 5)).one()
>>> u2 = session.scalars(select(User).where(User.id == 5)).one()
>>> u1 есть u2
Правда 

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

Когда отображаемый объект ORM загружается в память, есть три основных
способов обновить его содержимое новыми данными из текущей транзакции:

• метод expire() - метод Session.expire() будет
стереть содержимое выбранных или всех атрибутов объекта, чтобы они
будут загружены из базы данных при следующем обращении к ним, например. с использованием
ленивый шаблон загрузки:

   сессия.expire(u1)
  u1.some_attribute # <-- ленивая загрузка из транзакции 

• метод refresh() - тесно связан с Session.refresh()
метод, который делает все, что делает метод Session.expire()
но также немедленно выдает один или несколько SQL-запросов для фактического обновления
содержимое объекта:

   session.refresh(u1) # <-- генерирует запрос SQL
  u1.some_attribute # <-- обновляется из транзакции 

• метод populate_existing() или вариант выполнения - Это сейчас
вариант выполнения, задокументированный в Populate Existing; в
устаревшая форма, которую он нашел в объекте Query как
Метод Query.populate_existing() . Эта операция в любой форме
указывает, что объекты, возвращаемые запросом, должны быть безусловно
повторно заполнены из их содержимого в базе данных:

   u2 = session.scalars(
      select(User). where(User.id == 5).execution_options(populate_existing=True)
  ).один() 

Дальнейшее обсуждение концепции обновления/срока действия можно найти по адресу
Обновление / Срок действия.

См. также

Обновление/истечение срока действия

Я перезагружаю данные с помощью своего сеанса, но не вижу изменений, которые я зафиксировал в другом месте

UPDATE и DELETE с произвольным предложением WHERE

SQLAlchemy 2.0 включает расширенные возможности для генерации нескольких разновидностей
операторов INSERT, UPDATE и DELETE с поддержкой ORM. См.
документ в операторах INSERT, UPDATE и DELETE с поддержкой ORM для документации.

См. также

Операторы INSERT, UPDATE и DELETE с поддержкой ORM

ОБНОВЛЕНИЕ и УДАЛЕНИЕ ORM с пользовательскими критериями WHERE

Автоматический запуск

Объект Session имеет поведение, известное как autobegin .
Это указывает на то, что сеанс будет внутренне считать себя
находиться в «транзакционном» состоянии, как только выполняется какая-либо работа с
Сеанс , включая изменения внутреннего состояния
сеанс в отношении изменений состояния объекта или с
операции, требующие подключения к базе данных.

Когда сеанс создается впервые, транзакционный
состояние настоящее. Транзакционное состояние начинается автоматически, когда
такой метод, как Session.add() или Session.execute()
вызывается или аналогично, если Query выполняется для возврата
результаты (которые в конечном итоге используют Session.execute() ), или если
атрибут изменяется в постоянном объекте.

Состояние транзакции можно проверить, обратившись к
Метод Session.in_transaction() , который возвращает True или False
указывая, был ли выполнен шаг «автозапуск». Хотя обычно это не требуется,
метод Session.get_transaction() вернет фактический
Объект SessionTransaction , представляющий эту транзакцию.
состояние.

Транзакционное состояние сеанса также может быть запущено
явно, вызвав метод Session.begin() . Когда это
метод называется, Сессия помещается в «транзакционную»
заявлять безоговорочно. Session.begin() может использоваться как контекст
менеджер, как описано в разделе Создание блока начала/фиксации/отката.

Отключение автоматического запуска для предотвращения неявных транзакций

Поведение «автозапуск» может быть отключено с помощью
Параметр Session.autobegin установлен на False . Используя это
параметр, сеанс потребует, чтобы
Session.begin() метод вызывается явно. При строительстве, как
а также после любого из Session.rollback() ,
Session.commit() или Session.close() вызываются методы,
сеанс не будет неявно начинать какие-либо новые транзакции и будет
вызвать ошибку, если попытка использования сеанса производится без
первый вызов Session.begin() :

 с Session(engine, autobegin=False) в качестве сеанса:
    session.begin() # <-- требуется, иначе InvalidRequestError возникнет при следующем вызове
    session. add(Пользователь(имя="u1"))
    сессия.commit()
    session.begin() # <-- требуется, иначе InvalidRequestError возникнет при следующем вызове
    u1 = session.scalar(select(User).filter_by(name="u1")) 

Новое в версии 2.0: Добавлено Session.autobegin , позволяющее
Поведение «автозапуск» будет отключено

Совершение

Session.commit() используется для фиксации текущего
сделка. По своей сути это указывает на то, что он выдает COMMIT на
все текущие подключения к базе данных, в которых выполняется транзакция;
с точки зрения DBAPI это означает connection.commit()
Метод DBAPI вызывается при каждом соединении DBAPI.

При отсутствии транзакции для Сессия , указывающая
что в этом сеансе не выполнялись никакие операции с момента предыдущего
вызов Session.commit() , метод запустится и зафиксирует
только внутренняя «логическая» транзакция, которая обычно не влияет на базу данных
если не были обнаружены ожидающие изменения сброса, но все равно вызовет событие
обработчики и правила истечения срока действия объекта.

Операция Session.commit() безоговорочно выдает
Session.flush() перед отправкой COMMIT в соответствующую базу данных
связи. Если ожидающие изменения не обнаружены, SQL не передается в
база данных. Это поведение не настраивается и не зависит от
Параметр Session.autoflush .

После этого, Session.commit() затем СОВЕРШИТ фактический
транзакция базы данных или транзакции, если таковые имеются, которые существуют.

Наконец, срок действия всех объектов в сеансе истек, поскольку
сделка закрыта. Это делается для того, чтобы при следующих экземплярах
доступны либо через доступ к атрибутам, либо благодаря их присутствию в
результат SELECT, они получают самое последнее состояние. Такое поведение может быть
под контролем Флаг Session.expire_on_commit , который может быть
установите значение False , если такое поведение нежелательно.

См. также

Автоматический запуск

Откат

Session. rollback() откатывает текущую транзакцию, если таковая имеется.
Когда транзакций нет, метод проходит молча.

При сеансе, настроенном по умолчанию,
состояние после отката сеанса, следующее за транзакцией, имеющей
был начат либо через автозапуск
или по телефону Сессия.начать()
метод явно выглядит следующим образом:

• Откат всех транзакций и возврат всех соединений в
  пул соединений, если сеанс не был привязан непосредственно к соединению, в
  в этом случае соединение все еще сохраняется (но все же откатывается).

• Объекты, которые изначально находились в состоянии ожидания при добавлении
  к сеансу в течение срока службы
  транзакция удаляется, что соответствует их оператору INSERT,
  откат. Состояние их атрибутов остается неизменным.

• Объекты, которые были помечены как удаленные в течение срока службы
  транзакция возвращается в постоянное состояние, соответствующее
  их оператор DELETE откатывается. Обратите внимание, что если бы эти объекты были
  первая ожидающая внутри транзакции, эта операция имеет приоритет
  вместо.

• Срок действия всех объектов, которые не были удалены, полностью истек - независимо от
  Параметр Session.expire_on_commit .

Поняв это состояние, Сессия может
безопасно продолжить использование после отката.

Изменено в версии 1.4: объект Session теперь имеет отложенное поведение «начало», т.к.
описано в автозапуске. Если ни одна транзакция не
Начаты такие методы, как Session.commit() и
Session.rollback() не действуют. Такое поведение не будет
наблюдались до версии 1.4 как в режиме без автоматической фиксации,
транзакция всегда будет неявно присутствовать.

Когда Session.flush() дает сбой, как правило, по таким причинам, как основной
ключа, внешнего ключа или нарушения ограничения «не обнуляемый», выдается ROLLBACK
автоматически (в настоящее время промывка не может продолжаться после
частичный отказ). Однако сеанс переходит в состояние, известное как
«неактивен» в этот момент, и вызывающее приложение всегда должно вызывать
Session.rollback() явно, чтобы
Сеанс может вернуться в рабочее состояние (его также можно просто
закрыто и выброшено). См. запись часто задаваемых вопросов в разделе «Транзакция этого сеанса была отменена из-за предыдущего исключения во время сброса». (или аналогичный) для
дальнейшее обсуждение.

См. также

Автоматический запуск

Закрытие

Метод Session.close() выдает Session.expunge_all() , который
удаляет все объекты, отображаемые ORM, из сеанса и освобождает все
ресурсы транзакций/соединений от объекта(ов) Engine
к которому оно привязано. Когда соединения возвращаются в пул соединений,
транзакционное состояние также откатывается.

Когда сеанс закрывается, он, по существу, находится в
исходное состояние, как когда он был впервые построен, и можно использовать снова .
В этом смысле метод Session.close() больше похож на «сброс».
обратно в чистое состояние, а не как метод «закрытия базы данных».

Рекомендуется, чтобы объем сеанса был ограничен
вызов Session.close() в конце, особенно если
Session.commit() или Session.rollback() методы не
использовал. Сеанс может использоваться в качестве менеджера контекста для обеспечения
что Session.close() вызывается:

 с сеансом (двигателем) в качестве сеанса:
    результат = session.execute (выберите (пользователь))
# автоматически закрывает сеанс 

Изменено в версии 1.4: Объект Session имеет отложенное поведение «начало», т.к.
описано в автозапуске. уже не сразу
начинает новую транзакцию после того, как метод Session.close()
называется.

Часто задаваемые вопросы о сеансе

К этому моменту у многих пользователей уже есть вопросы о сеансах.
В этом разделе представлен мини-FAQ (обратите внимание, что у нас есть и настоящий FAQ)
из самых основных проблем, с которыми приходится сталкиваться при использовании Сессия .

Когда мне сделать

создатель сеансов ?

Только один раз где-то в глобальной области видимости вашего приложения. Должен быть
рассматривается как часть конфигурации вашего приложения. Если ваш
приложение имеет три файла .py в пакете, вы можете, например,
поместите строку sessionmaker в файл __init__.py ; от
этот пункт на других ваших модулях говорит «из сеанса импорта mypackage». Что
Кстати, все остальные просто используют Session() ,
и конфигурация этого сеанса контролируется этой центральной точкой.

Если ваше приложение запускается, импортирует, но не знает, что
базу данных, к которой он будет подключаться, вы можете привязать
Сессия на уровне «класса» до
движок позже, используя sessionmaker. configure() .

В примерах в этом разделе мы будем часто показывать
sessionmaker создается прямо над линией, где мы на самом деле
вызвать сеанс . Но это только для
пример ради! На самом деле сессионный мастер должен быть где-то
на уровне модуля. Вызовы для создания экземпляра Session
затем будет помещен в то место в приложении, где база данных
начинаются разговоры.

Когда я создаю сеанс

, когда его фиксирую и когда закрываю?

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

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

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

Некоторые примеры сценариев включают:

• Веб-приложения. В этом случае лучше всего использовать SQLAlchemy.
  интеграции, предоставляемые используемой веб-платформой. Или иначе,
  основной шаблон создать Сеанс в начале сети
  запрос, вызовите метод Session.commit() в конце
  веб-запросы, которые выполняют POST, PUT или DELETE, а затем закрывают сеанс
  в конце веб-запроса. Обычно также рекомендуется установить
  Session.expire_on_commit в False, чтобы последующие
  доступ к объектам, которые пришли из сеанса в рамках
  уровень представления не должен создавать новые SQL-запросы для обновления объектов,
  если транзакция уже совершена.

• Фоновый демон, порождаемый дочерними вилками
  хотел бы создать сеанс , локальный для каждого ребенка
  процесс, работа с этим Session на протяжении всей жизни «работы»
  что вилка обрабатывает, а затем разобрать ее, когда работа будет завершена.

• Для сценария командной строки приложение создаст один глобальный
  Сеанс , который устанавливается, когда программа начинает выполнять свою
  работу и фиксирует ее сразу же, как программа завершает свою задачу.

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

Как правило, приложение должно управлять жизненным циклом
сеанс извне к функциям, которые имеют дело с конкретными данными. Это
фундаментальное разделение задач, которое поддерживает операции, связанные с данными
независимо от контекста, в котором они получают доступ к этим данным и манипулируют ими.

Напр. не делай этого :

 ### это **неправильный способ** ###
класс ThingOne:
    деф идти (я):
        сеанс = сеанс()
        пытаться:
            session.execute (обновление (FooBar). значения (x = 5))
            сессия.commit()
        кроме:
            сессия.rollback()
            поднимать
класс ThingTwo:
    деф идти (я):
        сеанс = сеанс()
        пытаться:
            session.execute (обновление (виджет). значения (q = 18))
            сессия.commit()
        кроме:
            сессия.rollback()
            поднимать
защита run_my_program():
    ThingOne().go()
    ThingTwo().go() 

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

 ### это **лучший** (но не единственный) способ сделать это ###
класс ThingOne:
    def go(я, сеанс):
        session. execute (обновление (FooBar). значения (x = 5))
класс ThingTwo:
    def go(я, сеанс):
        session.execute (обновление (виджет). значения (q = 18))
защита run_my_program():
    с Session() в качестве сеанса:
        с session.begin():
            ThingOne().go(сеанс)
            ThingTwo().go(сеанс) 

Изменено в версии 1.4: сеанс может использоваться в качестве контекста.
менеджер без использования внешних вспомогательных функций.

Является ли сеанс кэшем?

Ага… нет. Он в некоторой степени используется как кеш, так как реализует
шаблон карты идентификации и хранит объекты, связанные с их первичным ключом.
Однако он не выполняет никакого кэширования запросов. Это означает, что если вы говорите
session.scalars(select(Foo).filter_by(name='bar')) , даже если Foo(name='bar')
находится прямо там, в карте удостоверений, сессия об этом не знает.
Он должен отправить SQL в базу данных, вернуть строки, а затем, когда он
видит первичный ключ в строке, , затем можно посмотреть в местной идентичности
карту и видим, что объект уже есть. Только когда ты говоришь
query.get({некоторый первичный ключ}) что
Сеанс не должен выдавать запрос.

Кроме того, сеанс хранит экземпляры объектов, используя слабую ссылку
по умолчанию. Это также противоречит цели использования сеанса в качестве кэша.

Сеанс не предназначен для
глобальный объект, с которым все консультируются как с «реестром» объектов.
Это больше работа кэш второго уровня . SQLAlchemy предоставляет
паттерн реализации кэширования второго уровня с помощью dogpile.cache,
через пример кэширования Dogpile.

Как получить сеанс

для определенного объекта?

Используйте метод класса Session.object_session()
доступно на сеансе :

 сеанс = Session.object_session(someobject) 

Также можно использовать более новую систему Runtime Inspection API:

 из проверки импорта sqlalchemy
сеанс = проверить (некоторый объект).  сеанс 

Является ли сеанс потокобезопасным?

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

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

Более важным моментом является то, что вы не должны хотеть, чтобы использовал сеанс
с несколькими параллельными потоками. Это было бы похоже на то, чтобы собрать всех вместе
в ресторане все едят из одной тарелки. Сеанс представляет собой локальное «рабочее пространство»
которые вы используете для определенного набора задач; вы не хотите или не должны,
поделиться этим сеансом с другими потоками, которые выполняют какую-то другую задачу.

Убедитесь, что Сеанс одновременно используется только в одном параллельном потоке.
называется подходом к параллелизму «ничего не разделять». Но на самом деле не
совместное использование сеанса подразумевает более значимый шаблон; это
означает не только сам объект Session , но и
также все объекты, связанные с этим сеансом , должны храниться в пределах
область действия одного параллельного потока. Набор отображаемых
объекты, связанные с сеансом , по существу являются прокси для данных
в строках базы данных, доступ к которым осуществляется через соединение с базой данных, и так же, как
Сама сессия , вся
набор объектов на самом деле просто крупномасштабный прокси для соединения с базой данных
(или связи). В конечном счете, в основном это само соединение DBAPI.
мы избегаем параллельного доступа; но с сеанса
и все объекты, связанные с ним, являются прокси для этого соединения DBAPI,
весь граф по существу небезопасен для одновременного доступа.