Перейти к основному содержимому
Версия: 1.23.3

Записи в структуре данных

В SimpleOne запись – это базовая сущность для хранения и представления информации. Она является объектом, содержащим заполненные значения атрибутов таблицы, к которой она относится. Запись соотносится со строкой реляционной базы данных.

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

Любая запись обладает набором полей, которые всегда заполняются системой при создании и/или изменении записи:

Записи таблиц определенного типа данных и назначения будут иметь обязательные поля:

  • Поле типа Record Class создается автоматически при создании дочерней таблицы и обозначает таблицу, к которой относится запись.
  • Для записей конфигурационных данных, обязательными полями являются Политика и Приложение.
  • Номер присваивается записям транзакционных таблиц, для которых настроена нумерация записей. В отличие от ID, нумерация является опциональной и настраивается дополнительно.

В SimpleOne взаимодействовать с записями можно через пользовательский интерфейс, а также через различные API (серверный API, REST API).

Операции с записями​

С записями могут взаимодействовать как пользователи, так и различные процессы. Эти виды взаимодействия представлены операциями создания, чтения, обновления, удаления (CRUD – create, read, update, delete).

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

Создание​

В момент создания записи пользователь работает с виртуальным объектом. До момента отправки в базу данных запись не существует. При отправке записи в базу данных, стартует транзакция, результатом которой является создание реальной записи в базе данных.

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

Чтение​

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

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

Обновление​

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

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

Dirty-атрибуты​

Атрибут считается dirty, если его значение изменилось, и не совпадает с предыдущим значением. Dirty-атрибутом также считается атрибут, значение которого меняется последовательно, как в примере ниже:

Последовательное изменение dirty-атрибутов
let prev = current.planned_end_datetime;
// в prev пустая строка ""
current.planned_end_datetime = '2024-02-13 12:12:12';
current.planned_end_datetime = prev;

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

внимание

Механизм dirty-атрибутов не срабатывает для записей следующих таблиц:

  • Индикаторы (sys_indicator)
  • Индикации (sys_indication)
  • Запланированные скрипты (sys_scheduled_script)
  • Запланированные импорты (sys_scheduled_import)
  • Запланированные задания (sys_scheduled_job)

Удаление​

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

Удаленные записи можно восстановить из Журнала удаления записей (sys_record_deletion_log), если на форме таблицы, к которой относится удаленная запись, установлен флажок Логировать удаление записей.

Уникальный ID записи​

Каждая запись в экземпляре определяется уникальным 18-символьным идентификатором, который хранится в колонке ID (sys_id).

ID записи уникален в пределах одной таблицы (включая записи в родительских/дочерних таблицах) и не может быть изменен после создания записи.

ID записи можно получить либо вручную из URL-адреса записи, либо при помощи скриптов.

Получение ID из URL-адреса записи​

Значение ID записи входит в состав URL-адреса, ведущего к этой записи. Например, запись статьи с URL, как в приведенном ниже примере, имеет ID, равный 158815469913225806.

https://<instance_url>/record/article/158815469913225806

Его можно получить либо из адресной строки браузера, либо скопировав URL-адрес элемента на панели навигации или в представлении списка.

Получение ID при помощи скрипта​

Значение ID можно получить не только вручную, но и с помощью скриптов.

  • На стороне сервера – из объекта SimpleRecord:
    • ss.addInfoMessage(current.sys_id);
  • На стороне клиента – с помощью метода s_form.getUniqueValue().