НАЧАЛО >> Руководство пользователя >> 📄 Скачать в DOCX

# Массовые операции с записями БД

Экспорт записей доступен из карточки Database через кнопку Управление БД... в меню Записи -> Экспорт записей.... Команда открывает окно параметров и по умолчанию ставит задачу Database/ExportRecords в очередь. Кнопка Запустить параллельно ставит задачу Database/ExportRecordsParallel с теми же параметрами и разбивает независимую часть работы на несколько дочерних queue-задач. Серверная задача не принимает произвольный путь выходного файла от пользователя: результат создается во внутреннем каталоге workdir/irbistool-export-records/<DB>/<ExportRunId>/records.iso или records.txt, рядом сохраняется exportrecords.manifest.json или exportrecords-parallel.manifest.json с отчетом выполнения. Для скачивания результата используется Database/DownloadExportRecords: страница заново проверяет права на БД и строит путь только по имени БД, идентификатору запуска и формату результата.

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

1. Экспорт записей

Рисунок 1 - Окно параметров экспорта записей

Окно параметров экспорта записей

Метод Database/ExportRecords для провайдера DP_Irbis64Native выполняет потоковый экспорт записей и покрывает базовые сценарии команды irbistool export по диапазону MFN и по списку MFN в ISO-2709 и текстовом формате.

Поддержанные параметры текущего инкремента:

Параметр Соответствие irbistool Назначение
FileName -f Путь к выходному файлу на provider-level. При запуске из интерфейса путь формируется сервером во внутреннем workdir, а не принимается от пользователя.
MfnFrom -mf или начало -r Первый MFN диапазона. Если не задан, используется 1.
MfnTo -mt или конец -r Последний MFN диапазона. Если не задан, используется последний MFN БД.
MfnList содержимое файла для -l Явный список MFN. Порядок и повторы сохраняются. Если список задан, диапазон не используется.
MfnListUploadId -l Идентификатор предварительно загруженного файла списка MFN. Файл загружается через Database/UploadExportMfnList во внутренний workdir, затем при экспорте переносится в каталог конкретного запуска и читается потоково.
ExportFormat=iso -iso Формат ISO-2709.
ExportFormat=text режим без -iso Текстовый формат #tag: value с разделителем записи *****.
Encoding=utf-8 режим по умолчанию Запись UTF-8.
Encoding=windows-1251 или win -win Запись Windows-1251.
RecHeader=true -hdr Добавляет строку #0: <MFN>#<status> в текстовом формате. Для ISO не используется.
SearchExpression -se Поисковое выражение для выборки MFN. Простые выражения из одного индексного терма, например "K=ANDROID", экспортируются потоково через postings; сложные boolean-выражения передают в экспорт iterable MFN без построения полного массива результата.
SequentialExpression -sc Последовательный PFT-поиск по уже выбранным записям. Если выражение не начинается с IF, оно выполняется как условие IF ... then '1' FI, как в irbistool.
FormatFilter -flt PFT-фильтр записи. Запись экспортируется только если результат форматирования начинается с 1. В irbistool фильтр передается как имя PFT-файла; в Database/ExportRecords передается текст формата.
FstContent -t FST-преобразование записи перед экспортом. В irbistool передается имя/путь FST-файла; в Database/ExportRecords передается текст FST.
FstUploadId -t Идентификатор предварительно загруженного FST-файла. Файл загружается через Database/UploadExportFst во внутренний workdir, затем при экспорте переносится в каталог конкретного запуска и читается как текст FST.
PrMarc=true PRMarc-ветка -t Специальный MARC-режим FST-экспорта. В irbistool включается, когда имя FST содержит значение PRMARCFORMAT из INI; в Database/ExportRecords включается явным флагом, так как веб/API-вызов передает текст FST, а не произвольный серверный путь.
Chunks - Число дочерних диапазонов для Database/ExportRecordsParallel. Для обычного Database/ExportRecords параметр не влияет на выполнение.
CleanupRetentionDays - Число дней хранения старых каталогов результата этой БД. По умолчанию 14; 0 отключает очистку по возрасту.
CleanupMaxRuns - Максимальное число каталогов результата этой БД с учетом текущего запуска. По умолчанию 20; 0 отключает очистку по количеству запусков.

Экспорт выполняется последовательно по MFN и не загружает БД целиком в память. Логически и физически удаленные записи пропускаются так же, как в irbistool export. Слишком длинные поля обрезаются по ISO-ограничению до 9999 байт вместе с разделителем поля; поля с меткой больше 999 экспортируются через резервную метку 998 с префиксом 998:, что повторяет поведение RecIsoWriteBuf.

Текстовый экспорт повторяет поведение RecTextWrite: для БД формата 2018+ без FST записывает служебный GUID как строку #2147483647: ..., затем выводит поля в физическом порядке записи и завершает каждую запись строкой *****. В режиме RecHeader=true статусная строка строится как у irbistool -hdr: #0 для обычной записи или набор битов блокировки, неактуальности, логического удаления и неактуального полного текста.

Во время фонового экспорта action Database/ExportRecords передает callback прогресса в публичный метод Database::ExportRecords. Native provider обновляет прогресс по обработанным MFN и сообщает счетчики processed, read, exported и skipped в монитор очереди. Если callback возвращает отмену, временный файл результата не публикуется как готовый экспорт.

Если перед экспортом выполняется сложный SearchExpression, provider дополнительно отправляет heartbeat activity уже на стадии поиска по словарю и postings. Поэтому в очереди может обновляться описание операции до того, как начнут расти счетчики прочитанных и экспортированных записей. Отмена через callback прерывает и эту поисковую стадию; ошибка поиска возвращается как ошибка экспорта, а не как пустая выборка.

Параллельный экспорт через Database/ExportRecordsParallel использует тот же публичный путь Database::ExportRecords в дочерних задачах. Parent-задача разбивает диапазон MFN, inline-список MFN, загруженный список MFN или результат SearchExpression на части, запускает Database/ExportRecordsRange, а затем последовательно объединяет part-файлы в один итоговый файл. FormatFilter, SequentialExpression, FstContent, загруженный FST и PrMarc передаются дочерним задачам как параметры обычного экспорта; provider context остается внутри Database/DP_Irbis64Native. Для SequentialExpression с результатом BREAK parent оставляет в итоговом файле только части до первого chunk с BREAK включительно и игнорирует более поздние chunk-выходы, сохраняя порядок результата.

Параллельный режим полезен, когда чтение/форматирование записей заметно тяжелее накладных расходов Queue и доступно несколько worker-потоков. На малых диапазонах обычный экспорт может быть быстрее из-за затрат на постановку child-задач и merge. Параллельный экспорт не выполняет одновременную запись в БД: дочерние задачи пишут только свои временные part-файлы, а итоговый merge выполняется parent-задачей последовательно.

В интерфейсе нельзя принимать произвольный путь к серверному файлу списка MFN как прямой аналог irbistool export -l. Безопасный вариант - передавать сами значения MFN или использовать отдельный upload, который сохраняет файл во внутренний рабочий каталог операции.

Для больших списков MFN в окне есть поле загрузки файла. Кнопка Загрузить список отправляет файл в Database/UploadExportMfnList, получает MfnListUploadId и передает этот идентификатор в queue-задачу Database/ExportRecords. Загруженный файл не открывает произвольный server-side путь: при запуске экспорта он переносится в каталог результата как mfn-list.txt, а provider читает MFN построчно.

SearchExpression для простого одиночного терма использует потоковый postings-итератор и не формирует полный MFN-список перед экспортом. Для сложных boolean-выражений DP_Irbis64Native/Search возвращает внутренний iterator MFN: обычные наборы идут через компактный BitList, который перебирается по битам без toIntArray(), а координатные выражения выдают ключи уже построенного postings-набора. Это убирает отдельный полный массив MFN перед экспортом; для терабайтных БД все равно нужно отдельно проверять память и время сложных координатных запросов, потому что сами postings для операторов расстояния могут быть крупными.

Для координатных выражений без tag-квалификаторов X (G) Y и X (F) Y провайдер использует compact-путь: он строит результат как BitList MFN и не сохраняет полный массив postings в памяти. Такие же компактные пересечения применяются к цепочкам из простых (G)/(F) пар. Для широких пустых ./near-выражений с масками или усечением выполняется предварительная проверка глобального пересечения tag/occ; если пересечения нет, экспорт получает пустую выборку без materialization postings. Базовые tag-квалификаторы проверены на малой и большой БД; непустые сложные ./near` и сценарии, которым нужны сами postings, остаются предметом отдельной проверки на больших БД.

SequentialExpression применяется к каждой прочитанной записи после основной выборки диапазоном, списком или поиском. Это потоковая проверка без накопления MFN, но она требует чтения каждой записи выбранного диапазона, поэтому на больших БД ее стоимость линейна по числу проверяемых записей. Результат BREAK останавливает экспорт, как в irbistool.

FormatFilter выполняется после чтения текущей записи и до записи результата в файл. Фильтр не накапливает список MFN и не меняет потоковую модель экспорта, но время операции зависит от сложности PFT-формата и возможностей PHP-реализации Format64.

FstContent создает виртуальную экспортируемую запись по правилам FST. В текущем покрытии проверены простой сценарий 200 0 v200, сценарий с копированием непереформатированных полей 200 0 v200 + 0 0 '*', строка @included при наличии файла included.fst и реальные таблицы BUS2.FST, QueryToRec.fst, BUSU.FST из IBIS: результат совпадает с irbistool -t побайтно для ISO и text. При копировании 0 0 '*' исходные поля переносятся из raw-представления в физическом порядке записи, поэтому пустые подполя сохраняются. Значимые пробелы, возвращенные FST-форматом, не обрезаются. При FST-преобразовании текстовый экспорт не выводит GUID отдельной служебной строкой, что повторяет вызов RecTextWrite в irbistool с отключенным guid.

В исходниках irbistool есть общий загрузчик текстовых ресурсов LoadEmbededResourse, который разворачивает строки вида @name как включение соседнего ресурса с тем же расширением. Однако фактический путь команды export -t в irbis_server_proc.cpp читает FST через LookupFile(..., ".fst") и LoadFromFile, а вызов LoadEmbededResourse оставлен закомментированным. Поэтому Database/ExportRecords для export -t тоже не разворачивает строки @...: такие строки не являются FST-правилами и игнорируются парсером, что подтверждено compare-сценарием range-*-fst-at-line-ignored-*.

Если FST неудобно вставлять в поле FstContent, окно экспорта поддерживает безопасную загрузку файла. Кнопка Загрузить FST отправляет файл в Database/UploadExportFst, получает FstUploadId и передает его в queue-задачу. Загруженный FST не открывает произвольный server-side путь: при запуске экспорта файл переносится в каталог результата как export.fst, читается оттуда и фиксируется в exportrecords.manifest.json. Одновременно передавать FstContent и FstUploadId нельзя, чтобы избежать неоднозначного источника таблицы.

PrMarc=true повторяет специальную ветку irbistool для MARC FST: перед переформатированием во временную запись добавляется поле 1001 со значением ^A2, после FST-преобразования разделители подполей ^ заменяются на управляющий символ 0x1F, первое поле 999 удаляется из экспортируемых данных и используется для корректировки лидера ISO. В отличие от irbistool, где режим определяется именем FST-файла, в ИРБИС 128 режим включается явным параметром, потому что API принимает безопасный текст FST.

Перед созданием нового результата Database/ExportRecords очищает старые каталоги workdir/irbistool-export-records/<DB> по лимитам CleanupRetentionDays и CleanupMaxRuns. Очистка ограничена каталогом текущей БД и не затрагивает произвольные пути. Общий каталог _uploads, текущий ExportRunId и каталоги с именами вне whitelist не удаляются. В отчете задачи и manifest сохраняется блок Cleanup с числом просмотренных и удаленных каталогов.

Queue-запуск сохраняет тот же отчет, что и прямой action: количество прочитанных, экспортированных и пропущенных записей, размер файла, время, peak memory, DownloadUrl и блок Cleanup. Параллельный отчет дополнительно содержит childTasks, сведения о split-режиме, part-файлах, break/breakMfn для последовательного поиска и merge-статистику. Результат остается доступен для скачивания через Database/DownloadExportRecords.

2. План слияния БД

Рисунок 2 - Окно параметров слияния БД

Окно параметров слияния БД

Для подготовки будущей операции irbistool mergedb добавлен backend-метод Database/MergeDbDryRun. Он строит недеструктивный preflight-план слияния нескольких исходных БД в текущую БД-приемник, но не выполняет перенос записей, FT или словарей.

Database/MergeDbDryRun предназначен для диагностики и предварительной оценки. Отчет явно содержит dryRun=true, writePerformed=false и implemented=false, чтобы результат нельзя было принять за выполненное слияние.

Поддержанные параметры:

Параметр Соответствие irbistool mergedb Назначение
SourceDbNames -src Список исходных БД. Можно передать массив или строку со значениями через пробел, запятую или точку с запятой.
текущая Database -dst БД-приемник. Вызов идет через объект текущей БД, поэтому внешний код не обращается к provider context напрямую.

MergeDbDryRun запрещает ситуацию, когда БД-приемник входит в список исходных БД. Для каждой БД provider открывает файлы только в read-only-режиме, определяет MaxMfn, наличие embedded FT-БД, рассчитывает mfnShift и ftMfnShift, собирает известные файлы MST/XRF/CNT/N01/N02/L01/L02/IFP/ANY/PAR и оценивает объем backup/work/free-space. Оценка места является preflight-подсказкой для администратора и будущей queue-задачи; она не заменяет фактический backup перед destructive-операцией.

Пользовательская команда Записи -> Слияние БД... доступна из окна управления БД и запускает queue-задачу слияния для текущей БД-приемника. В форме видны только БД-источники, флажок загрузки словаря после слияния, подтверждение backup и комментарий к backup/rollback. Операция требует права EDIT, подтверждение backup, пустую БД-приемник и внутренний серверный допуск к destructive-режиму; без подтверждения backup action не запускается даже при прямом queue-вызове. Перед записью создается backup-manifest destination-файлов, записи переносятся raw append-путем без декодирования полей, физически удаленные MFN сохраняются как физически удаленные позиции destination, а при ошибке после записи выполняется восстановление backup. Текущий irbistool.exe mergedb на проверенном real-FT fixture не переносит embedded FT-записи, поэтому пользовательская форма также не показывает отдельный FT-copy режим. После записи выполняются post-merge проверки diagmfn, diagmstxrf, diagrec, diaglnk после загрузки словаря и, при наличии FT-стадии, diagrecft; результат возвращается в отчете задачи.

Dry-run дополнительно возвращает dictionaryPlan для будущей словарной стадии. Это план рабочих файлов и стадий export -> shift/sort -> load -> diaglnk; каталог irbistool-mergedb/<runId> при dry-run не создается, словарные файлы не пишутся и загрузка N01/L01/IFP не выполняется. Пользовательскую операцию слияния нельзя считать готовой только по этому плану: он нужен для последующего отдельного commit/rollback-проекта словарей.

Для следующего недеструктивного инкремента добавлен Database/MergeDbDictionaryDryRun. Метод создает workdir словарной стадии, формирует catalog term chunks для destination и source-БД, применяет cumulative MFN-shift к postings source-БД и строит общий terms-sorted.jsonl. Он не вызывает loaddict, не пишет N01/L01/IFP, возвращает writePerformed=false и destructiveLoadPerformed=false. Проверочный сценарий ARCH <- CMPL,RQST сформировал ненулевой sorted stream: 352 term rows, 381 postings; source CMPL получил shifted MFN 62..66, source RQST - 387..393 в диагностическом лимите первых 5 записей на БД. Это закрывает только подготовку shift/sort; destructive load, backup/rollback словарей и diaglnk остаются отдельной стадией.

Первый destructive load-gate словарей выполняется только на изолированной временной копии внутри tools/DP_Irbis64NativeMergeDbMstXrfPrototypeSelfTest.php. Тест строит sorted stream до полного MST/XRF merge, выполняет MST/XRF append на temp destination, сначала отменяет LoadIndexTermsCatalog через progress callback после начала stage-записи и проверяет, что committed N01/L01/IFP остались с исходными SHA1, затем загружает stream штатно. Успешная загрузка возвращает ненулевые счетчики dictTerms=5019, dictPostings=20936, проходит catalog-only DiagLnk, после чего N01/L01/IFP восстанавливаются из SHA1 baseline. Это подтверждает, что подготовленный поток можно загрузить после append-записей и что отмена до установки индекса не портит committed index files, но не заменяет production commit/rollback и не включает FT dictionary.

Расширенный compare tools/DP_Irbis64NativeMergeDbCompare.php ... --with-dictionary-load проверяет multi-source словарную ветку на временной native-копии: stream строится до MST/XRF append, загружается после append, затем выполняется native catalog-only DiagLnk и сканируются postings. Прогон CMPL,RQST -> SPRAV прошел с dictTerms=5975, dictPostings=22451, native diaglnk=ok, без postings на физически или логически удаленные записи. В той же проверке irbistool.exe mergedb завершился с кодом 0, но напечатал sorting error ... length=260, а его итоговый L01 не прошел DiagLnk; это документируется как дефект утилиты и не переносится в native-поведение.

Пользовательское окно намеренно не выводит исследовательские параметры переноса FT, частичного слияния, искусственных сбоев, настройки рабочих chunks/run-id и служебные флаги временных незарегистрированных копий. Эти режимы остаются только для self-test/compare. Отдельный FT-copy режим требует нового product gate.

Product decision по отдельному FT-copy режиму зафиксирован: в первом пользовательском UI mergedb не должен показывать отдельную опцию переноса embedded FT. По умолчанию режим остается совместимым с текущим irbistool.exe, который на проверенном real-FT fixture не переносит embedded FT-записи. Явный MergeFullText=true сохраняется только как internal/research-флаг для compare/self-test и будущего отдельного решения; он не должен попадать в пользовательскую форму без нового product gate.

Открытой остается внешняя зависимость от реального fragmented/old-version fixture: текущий стенд не содержит пригодной реальной БД такого класса, поэтому synthetic guard сохраняется как защита, но не считается полной заменой real fixture parity.

Проверка текущего preflight-инкремента выполняется скриптом tools/DP_Irbis64NativeMergeDbDryRunSelfTest.php. На стенде C:\i128\instances\irbis128.local\irbis64, сценарий ARCH <- IBIS вернул mfnShift=61, records=7228, requiredFreeBytes=168656996, dictionaryPlan и подтвердил отказ при dst внутри src; self-test также проверяет, что dictionaryPlan.workDir не создается при dry-run. Сценарий ARCH <- CMPL,RQST подтверждает cumulative mfnShift для нескольких source. Проверка MST/XRF prototype выполняется tools/DP_Irbis64NativeMergeDbMstXrfPrototypeSelfTest.php: сценарий на временных копиях CMPL -> SPRAV с лимитом 5 записей подтвердил отказ без AllowPrototypeWrite, отказ при недостатке свободного места до создания backup, rollback после искусственного сбоя InjectFailureAfterRecords=2, finalMaxMfn=6, успешные DiagMfn/DiagMstXrf/DiagRec, наличие post-merge diagnostics и совпадение raw-содержимого первой перенесенной записи после ожидаемой переписи leader. Для FT self-test создает synthetic embedded FT-пространства на временных копиях, подтверждает fullTextCopied=2 при полном prototype-run с явным MergeFullText=true и проверяет rollback main/FT snapshot при искусственном сбое InjectFailureAfterFullTextRecords=1 после записи основной части и первой FT-записи.

Пользовательская операция слияния выведена только в ограниченном режиме MST/XRF + catalog dictionary с обязательным backup-подтверждением и без FT-copy опции. Реальный fragmented/old-version coverage остается внешней fixture-зависимостью; при обнаружении такой БД destructive merge должен повторно пройти compare/preflight gates.

Rollback prototype merge удаляет не только восстановленные из backup файлы. Backup-manifest сохраняет снимки каталогов destination, где находятся резервируемые файлы, а rollback удаляет extra-файлы, появившиеся там после создания backup; счетчик возвращается как rollback.removedExtra. Self-test покрывает это через InjectExtraFileBeforeRollback=true после FT dictionary load, чтобы проверить восстановление состояния каталога, а не только замену известных файлов.

Для проверки Queue-пути добавлен action Database/MergeDbMstXrfPrototype и restore-test tools/DatabaseMergeDbQueueRestoreTest.php. Тест создает временные незарегистрированные копии source/destination в irbis64/datai, проверяет rollback после injected dictionary-load failure и затем успешный Queue-сценарий без injected failure. Повторный контрольный прогон CMPL -> SPRAV после включения BackupConfirmed создал rollback task 517281 со state=3, copied=323, dictionaryTerms=4308, rollbackRestored=11 и восстановлением 38 файлов snapshot; успешный task 517282 завершился state=2, copied=323, dictionaryTerms=4308, dictionaryPostings=7195, diaglnkOk=true, postMergeDiagnosticsOk=true. Action также передает ProgressCallback в Database::MergeDbMstXrfPrototype и отображает стадии preflight, backup, records, dictionary-load, diagnostics и complete через queue progress/heartbeat.

Расширенный compare без словарной загрузки выполнен на большей БД RPC -> SPRAV: MaxMfn=95900, структурно сравнено 95899 записей, native перенес 95899 записей без физически удаленных MFN, время native 4.232021 с против irbistool=24.588030 с. Этот прогон дополнительно закрыл проблему повторного открытия больших разреженных XRF-файлов: определение 8/12-байтового XRF теперь сбрасывает cache при смене формата и проверяет контрольные MFN дальше первых 100 записей.

Средний real-fixture compare со словарной загрузкой выполнен на IBIS -> SPRAV --with-dictionary-load: native перенес 7225 записей, сохранил 3 физически удаленных MFN, построил catalog dictionary на 14950 термов / 102887 postings и прошел DiagLnk; время native 6.905654 с. В этом сценарии текущий irbistool.exe завершает процесс с exit code 0, но сообщает result -401 / Inverted file error (Irbisinitpost) при копировании словаря IBIS и оставляет невалидный N01. Такое повреждение словаря считается дефектом утилиты и не переносится в native-реализацию.

3. Реорганизация MST/XRF

Команда Актуализация -> Реорганизовать MST/XRF... в окне Управление БД... запускает фоновую задачу Database/ReorgMasterFile для текущей БД. Это разрушающая операция над master file и XRF, поэтому перед запуском нужна актуальная резервная копия или заранее подготовленная тестовая копия БД.

Команда Актуализация -> Реорганизовать MST/XRF без удаленных записей... удаляет логически удаленные записи из физической структуры БД. Для провайдера DP_Irbis64Native она выполняется нативно: сервер создает рабочий каталог workdir/native-reorg-exclude-deleted/<DB>/reorg-..., сохраняет backup файлов БД, перестраивает MST/XRF без логически удаленных записей, затем пересоздает словарь. Результат запуска и параметры backup фиксируются в manifest.json в каталоге операции.

Рисунок 3 - Команда реорганизации MST/XRF без удаленных записей в меню Актуализация

Команда реорганизации MST/XRF без удаленных записей в меню Актуализация

Рисунок 4 - Подтверждение нативной реорганизации MST/XRF без удаленных записей

Подтверждение нативной реорганизации MST/XRF без удаленных записей

Если нативная реорганизация MST/XRF завершилась успешно, задача возвращает сообщение Native MST/XRF reorganization and dictionary rebuild completed. Если MST/XRF перестроены, но пересоздание словаря завершилось ошибкой, задача помечается ошибочной и сообщает, что требуется повторная перестройка словаря. Для провайдеров без нативной поддержки или для обычной команды без исключения удаленных записей сохраняется путь через irbistool reorgmf / reorgexmf.

После выполнения операции администратор должен проверить состояние БД в том же окне командой База данных -> Обновить состояние и при необходимости выполнить диагностику MST/XRF и словаря. На рабочей БД нельзя запускать реорганизацию параллельно с импортом, глобальной корректировкой, слиянием БД или другой операцией, которая пишет в MST/XRF.

4. Глобальная корректировка

Глобальная корректировка доступна из карточки Database через кнопку Управление БД... в меню Записи -> Глобальная корректировка.... Окно ставит задачу Database/RunGlobalCorrection в очередь и предназначено для операций, которые изменяют записи.

Поддержанные параметры текущего инкремента:

Параметр Соответствие irbistool global Назначение
GblContent -f Текст GBL-задания. В интерфейсе можно ввести текст напрямую или загрузить GBL-файл во внутренний workdir. Произвольный server-side путь не принимается.
MfnFrom, MfnTo -mf, -mt, -r Диапазон MFN. Если выборка списком или поиском не задана, корректировка идет по диапазону, а при пустом конце диапазона - до последнего MFN БД.
MfnList, MfnListUploadId -l Список MFN текстом или загруженным файлом. Порядок и повторы сохраняются.
SearchExpression -se Поисковая выборка MFN. Для DP_Irbis64Native используется native MFN-итератор ReturnMfnIterable; для провайдеров без такого пути остается fallback через список MFN.
SequentialExpression -sc PFT-условие последовательного отбора. Проверяется по одной прочитанной записи, без загрузки всей БД в память. Если выражение не начинается с IF, оно нормализуется как условие IF ... then '1' FI.
Autoin -a Выполнять autoin при сохранении записей.
FLC -c Выполнять формально-логический контроль.
UpdateIndex -u Актуализировать словарь при сохранении.
ChunkSize - Размер пакета MFN, передаваемого в Database::DoGblForList.

Серверная функция Database/RunGlobalCorrection инкапсулирует выборку и вызывает существующий Database::DoGblForList; внешний UI/action слой не обращается к контексту провайдера напрямую. В native-режиме поисковая выборка перебирается как iterable MFN без построения отдельного полного массива результата. Результат задачи сохраняется в workdir/irbistool-global/<DB>/<RunId>/global.manifest.json; рядом создается журнал global.log, который можно скачать через Database/DownloadGlobalCorrectionLog. Для больших диапазонов параметр ChunkSize задает размер пакета MFN; по умолчанию используется 1000, верхний предел 10000. Progress обновляется периодически, чтобы сохранить heartbeat длительной операции без лишних вызовов на каждом MFN.

Соответствие базовых режимов проверяется сценарием tools/DP_Irbis64NativeGlobalCompare.php: на изолированных копиях IBIS результаты range, list, search, scan, update-index, базового NEWREC, NEWREC + -a и NEWREC + -c совпали с irbistool.exe global. Поисковый режим использовал ReturnMfnIterable, update-index подтвердил создание термина после -u/UpdateIndex, NEWREC подтвердил создание новой записи через GBL-блок, -a применил autoin.gbl к созданной записи, а -c пометил созданную запись логически удаленной по dbnflc.pft. Full-size benchmark на RPC, диапазон 1..95899, GBL ADD 901 'I128GLOBALFULLSIZE20260624', после оптимизации bulk-записи показал native 26.784726 с против irbistool=27.972823 с; peak memory PHP-процесса 14680064 байт.

Перед запуском на рабочей БД нужна актуальная резервная копия или выполнение на копии БД. Операция может изменить MST/XRF, создать новые записи через GBL и изменить состояние индекса при включенном UpdateIndex. Runtime/compare с irbistool.exe global должен выполняться на изолированной копии БД.

Очередь задач обеспечивает фоновое выполнение и мониторинг, но сама по себе не делает безопасной параллельную запись в одну БД. Для одной MST/XRF/IFP/N01/L01 массовые write-операции должны выполняться последовательно или через специально спроектированную схему с блокировками, временными файлами, последовательным merge/commit и проверенным rollback. Параллелизм уместен для независимых БД, read-only диапазонов, экспорта, диагностики и подготовительных стадий, которые не пишут одновременно в один набор файлов БД.

5. Обновление записи из протокола recupdate

Для backend-сценариев добавлен метод Database/RecUpdateProtocolRecord. Он принимает одну запись в протокольном формате irbistool recupdate: первая строка содержит mfn#status, вторая - 0#version, следующие строки - tag#value. Внешний UI/action слой должен вызывать именно Database, а не контекст провайдера напрямую.

В текущем инкременте пользовательского окна для этой операции нет. Метод предназначен для последующего подключения безопасной загрузки протокольного файла через очередь после UX-решения по backup/rollback и месту хранения отчетов.

Поддержанные режимы:

Параметр Соответствие irbistool recupdate Назначение
ProtocolContent -if Текст одной протокольной записи.
FileName -if Файл протокольной записи, разрешаемый через провайдер.
MstUpdate=true -mstupdate Записать запись в MST/XRF без актуализации словаря.
MstUpdate=true, IfUpdate=true -mstupdate -ifupdate Записать запись и актуализировать словарь.

Чистый режим recupdate -ifupdate не эмулируется. В проверенном irbistool.exe он возвращает REC_PHYS_DELETE (-605) для существующей записи и не обновляет индекс; исходный код ведет эту ветку через IrbisRecIfUpdateTime после DecodeRecord. Это зафиксировано как дефект/ограничение irbistool, а не как целевое поведение ИРБИС 128. Для актуализации существующей записи следует использовать Database/RecIfUpdate или Database/RecIfUpdateAll.

При актуализации индекса действует обязательный инвариант: логически удаленные (BIT_LOG_DEL) и физически удаленные (BIT_PHYS_DEL) записи не должны иметь postings в словаре. Это нужно, чтобы поисковая выдача не могла вернуть удаленную запись. Native-инвертор удаляет старые postings такой записи и не добавляет новые; это покрыто tools/DP_Irbis64NativeRecUpdateSelfTest.php.

Дополнительно DP_Irbis64Native/Search фильтрует MFN по XRF-флагам перед возвратом обычной выдачи и потокового ReturnMfnIterable. Это защищает пользовательскую выдачу, экспорт и глобальную корректировку по поисковой выборке от старых postings, которые могли остаться в неконсистентном индексе до актуализации или полной перестройки.

Соответствие проверяется сценарием tools/DP_Irbis64NativeRecUpdateCompare.php на изолированных копиях БД. Сценарий сравнивает -mstupdate и -mstupdate -ifupdate с DP_Irbis64Native/RecUpdateProtocolRecord, а чистый -ifupdate проверяет как диагностический отказ без применения ошибочной эмуляции к рабочей БД.

6. Импорт записей

Рисунок 5 - Окно параметров импорта записей

Окно параметров импорта записей

Импорт записей доступен из карточки Database через кнопку Управление БД... в меню Записи -> Импорт записей.... Команда открывает окно параметров, позволяет безопасно загрузить файл записей и FST во внутренний каталог workdir/irbistool-import-records/<DB>/_uploads, требует подтверждения наличия резервной копии и затем ставит задачу Database/ImportRecords в очередь. Серверная задача не принимает произвольный путь к входному файлу от пользователя: при запуске загруженный файл переносится в каталог конкретного запуска workdir/irbistool-import-records/<DB>/<ImportRunId>/records.dat, рядом сохраняется importrecords.manifest.json с отчетом выполнения.

Во время фонового импорта Database/ImportRecords передает в Database/ImportFromFile callback прогресса. Native provider обновляет прогресс по фактически прочитанным байтам входного файла и сообщает текущие счетчики read/imported в монитор очереди. Это позволяет видеть heartbeat длительного импорта без загрузки всего файла в память.

Database/ImportRecords использует Database/ImportFromFile и покрывает реализованные provider-level сценарии irbistool import: ISO-2709, текстовый формат, CSV, FST-преобразование, -guid, -hdr, -flt, -pdel, -k и -c.

Поддержанные параметры текущего инкремента:

Параметр Соответствие irbistool Назначение
ImportUploadId -f Идентификатор предварительно загруженного файла записей. Файл загружается через Database/UploadImportRecords и переносится в каталог запуска.
BackupConfirmed=1 требование ИРБИС 128 Обязательное подтверждение, что перед импортом есть актуальная резервная копия БД и понятен сценарий отката. Без этого параметра Database/ImportRecords не запускает импорт.
BackupNote журнал ИРБИС 128 Комментарий оператора к резервной копии или откату; сохраняется в manifest.
ImportFormat=auto автоопределение Provider сам определяет ISO по 5-байтовой длине записи; остальные файлы считаются текстовыми, если явно не выбран CSV.
ImportFormat=iso -iso ISO-2709.
ImportFormat=text режим без -iso Текстовый формат #tag: value с разделителем *****.
ImportFormat=csv -csv CSV с разделителем ;, кавычками, "" и многострочными quoted values.
Encoding=utf-8 режим по умолчанию irbistool Чтение UTF-8.
Encoding=windows-1251 или win -win Чтение Windows-1251.
FstContent -t Текст FST-преобразования, выполняемого перед сохранением записи.
FstUploadId -t Идентификатор предварительно загруженного FST-файла. Файл загружается через Database/UploadImportFst, затем переносится в каталог запуска как import.fst и читается как текст FST.
Guid=true -guid Сохраняет служебный GUID 2147483647 из текстового импорта.
Header=true -hdr Учитывает строку #0 текстового импорта и позволяет сохранить MFN/статус для новой записи.
FormatFilter -flt PFT-фильтр импорта. Запись сохраняется только если результат форматирования начинается с 1.
PhysicalDeleted=true -pdel Для новых записей без MFN переиспользует физически удаленные MFN в XRF перед добавлением записей в конец БД.
CheckCoding=true -k Проверяет UTF-8 строк полей перед сохранением и отбрасывает записи с невалидной кодировкой.
UseFLC=true -c Выполняет формально-логический контроль через dbnflc.pft/настройку DbnFlc. Фатальная ошибка ФЛК сохраняет запись как логически удаленную, как в irbistool.
UseAutoin=true -a Выполняет autoin.gbl после чтения записи, FST и фильтра, но до ФЛК, проверки кодировки и записи.
MergePft -p PFT-ключ объединения: @<MFN>, имя PFT из файлов БД или inline PFT-текст. Целевая запись выбирается по MFN или первому posting терма.
MergeGbl -g Имя GBL из файлов БД или inline GBL-текст для коррекции импортируемой записи перед сохранением. Подтвержденный provider-level scope - коррекция текущей записи, NEWREC, NEWMFN '*' в той же БД и NEWMFN в другую БД на изолированном стенде; для побочных записей действует транзакционная rollback-группа, UseAutoin/UseFLC применяются к созданным GBL-записям перед их сохранением, а одиночная autoin-created каскадная запись сохраняется до родительской побочной записи.
ErrorLimit - Ограничивает число подробных ошибок в отчете.
MergeGblCreatedRecordDetailsLimit - Ограничивает число подробных элементов mergeGblCreatedRecordDetails в отчете для MergeGbl с побочными записями. Полный объем отражается в summary-полях mergeGblCreatedRecordDetailsTotal, mergeGblCreatedRecordDetailsOmitted и mergeGblCreatedRecordDetailsTruncated.

Импорт читает входной файл последовательно по одной записи и не загружает весь файл в память. ISO-2709 читается по 5-байтовой длине записи, text - до разделителя *****, CSV - по одной CSV-записи. Для append-import без FST, фильтра, ФЛК, autoin, merge и PhysicalDeleted provider использует одну bulk-транзакцию на поток записей; это включает CheckCoding=true, потому что проверка кодировки выполняется до записи и не создает побочных записей. В отчете это видно как bulkAppendTransaction=true. В отчете задачи фиксируются read, imported, filtered, flcRejected, flcWarnings, codingRejected, reusedPhysicalDeleted, bulkAppendTransaction, errors, seconds, peakMemory и параметры запуска.

importrecords.manifest.json является проверяемым артефактом запуска. В нем должны быть зафиксированы ImportRunId, исходный ImportUploadId, имя БД, формат импорта, кодировка, параметры запуска, подтверждение backup, комментарий к backup/rollback, путь рабочего каталога, путь перенесенного records.dat, путь import.fst при загрузке FST, provider-отчет со счетчиками, время выполнения, peakMemory и список ошибок в пределах ErrorLimit.

Фатальная ошибка ФЛК в irbistool не пропускает MFN: запись сохраняется как логически удаленная. Поэтому при UseFLC=true число импортированных записей включает такие MFN, а подробности нужно смотреть по счетчику flcRejected и протоколу задачи.

UI включает UseAutoin, MergePft и MergeGbl только после обязательного подтверждения backup. Эти режимы уже сверяются с irbistool на provider-level в ограниченных сценариях. Для MergeGbl runtime Queue path дополнительно проверен на IBIS3: задача 512930 передала MergeGbl=queue_mergegbl, provider вернул mergeGbl=true, mergeGblApplied=2, а импортированные записи получили контрольное поле 901. Provider-level compare дополнительно подтверждает NEWREC, NEWMFN '*' в той же БД и NEWMFN 'ARCH' в другую БД: побочная запись получает MFN перед основной или в целевой БД, счетчик mergeGblCreatedRecords=1, а mergeGblCreatedRecordDetails фиксирует DB/MFN/result. Сценарии MergeGbl NEWREC и MergeGbl NEWMFN 'ARCH' вместе с UseAutoin и UseFLC подтверждают применение autoin и ФЛК к побочной записи перед ее сохранением в контексте целевой БД; основная импортируемая запись после -g пишется напрямую, как у irbistool. Сценарий MergeGbl NEWREC вместе с UseAutoin и autoin-created записью подтверждает порядок cascade -> side -> main: autoin-created запись получает первый MFN, родительская побочная запись второй, основная импортируемая запись третий. Для ошибки основной записи после записи побочной действует native rollback-группа: отчет возвращает mergeGblRollbacks=1, mergeGblRollbackDetails, rolledBack=true в detail побочной записи, а MaxMfn исходной и целевой БД не меняется; это проверено и для cascade+side в одной БД. Для структурной ошибки GBL, например отсутствующего include, provider возвращает mergeGblErrorDetails, не импортирует запись и оставляет MaxMfn неизменным. Общая рекурсия/UpdList, сложные циклы autoin/GBL и полная совместимость error-протокола остается отдельной задачей до расширения UI-подсказок и rollback-регламента.

Перед запуском импорта на рабочей БД нужно иметь актуальный snapshot или файловую копию БД. Откат массового импорта означает восстановление этой копии, а не отмену queue-задачи. Поэтому окно импорта и серверная задача требуют BackupConfirmed=1; комментарий BackupNote используется как след в журнале запуска, но не заменяет саму резервную копию. Это особенно важно для PhysicalDeleted, Header, UseFLC и будущих UI-режимов autoin/MergePft/MergeGbl: операция может занять MFN, изменить MST/XRF и оставить записи с признаком неактуальности словаря.

7. Ограничения текущего покрытия

Оставшиеся работы по irbistool import: расширенный backup/rollback-регламент для опасных режимов, сложная семантика IrbisGblRec с рекурсией/UpdList, сложными циклами autoin/GBL, полным runtime error-протоколом и дальнейшая оптимизация сложных режимов на больших входных файлах. Первый enforcement-инкремент закрыт: Database/ImportRecords не запускается без BackupConfirmed=1, а manifest сохраняет BackupConfirmed и BackupNote. Provider-level compare уже покрывает -pdel, -k, -c, -a, простой -g, -g с NEWREC, -g -a -c с NEWREC, -g -a с NEWREC и одиночной autoin-created записью, -g с NEWMFN '*' в той же БД, -g с NEWMFN 'ARCH' в другую БД, -g -a -c с NEWMFN 'ARCH' и -p; пользовательский upload/queue smoke проверен на зарегистрированной пустой тестовой БД IBIS3; runtime Queue file-set compare простого text-import и runtime Queue pass-through MergeGbl проверены на IBIS3 с backup/restore. Full-size benchmark на RPC покрывает append, CheckCoding, UseAutoin, простой MergeGbl и MergeGbl NEWREC; для MergeGbl bulk-транзакция разрешается только если GBL не содержит NEWREC, NEWMFN или PUTLOG.

Оставшиеся работы по irbistool export: расширение FST-покрытия на крупные реальные конверсионные таблицы, проверка непустых сложных координатных -se и ./near на больших выдачах, длительное production-наблюдение политики хранения результатов и дальнейшие full-size performance-повторы на больших БД. Малые координатные сценарии (G) и (F), широкие пустые (G)/(F), цепочки простых (G)/(F), пустые broad ./near и базовые tag-квалификаторы уже включены в compare/probe/benchmark-покрытие без OOM; отдельная проверка больших выдач нужна из-за объема postings, который требуется операторам расстояния в непустых случаях. Строки FST-включений @... для export -t покрыты как игнорируемые текущим irbistool.exe, а не как разворачиваемые ресурсы. Обычный Queue smoke с финальным progress=1 и скачиванием результата проверен на IBIS; параллельный Queue-export покрыт runtime-сравнениями range/list/upload/search/filter/FST/SequentialExpression/BREAK, но требует production-наблюдения на реальных больших заданиях.

8. Проверка соответствия

Импорт проверяется скриптом tools/DP_Irbis64NativeImportRecordsCompare.php: он создает изолированные копии IBIS, а для cross-DB NEWMFN дополнительно копию ARCH, запускает irbistool.exe import и native provider на одинаковых входных данных, сравнивает MaxMfn, статусы MST/XRF и контрольные MFN, проверяет монотонные вызовы progress callback, а также выводит время выполнения. Для NEWREC/NEWMFN compare дополнительно проверяет mergeGblCreatedRecordDetails: целевую БД, MFN, тип и результат записи. Отдельный tools/DP_Irbis64NativeImportIsoSelfTest.php проверяет потоковое чтение форматов, счетчики и память на fixture; tools/DatabaseImportRecordsFileSetCompare.php проверяет action-like перенос upload в run-dir, manifest и файловый набор БД/индекса. tools/DatabaseImportRecordsQueueFileSetCompare.php запускает реальную queue-задачу Database/ImportRecords на зарегистрированной IBIS3, сравнивает IFP/N01/L01 с irbistool, структурно проверяет MST/XRF, проверяет pass-through MergeGbl и восстанавливает backup БД. Последний runtime Queue запуск 512930 дал mergeGbl=true, mergeGblApplied=2, read=2, imported=2, errors=0. Provider-level merge-gbl-newrec и merge-gbl-newmfn дали created=1, createdMfn=7229, mainMfn=7230, maxMfn=7231; merge-gbl-newrec-autoin-cascade подтвердил каскадную запись autoin перед родительской побочной записью: created=2, cascadeMfn=7229, sideMfn=7230, mainMfn=7231; merge-gbl-cascade-rollback подтвердил откат cascade+side при ошибке основной записи: imported=0, errors=1, rollbacks=1, details=2, maxMfn=7229; merge-gbl-newmfn-alt подтвердил запись побочной записи в ARCH: createdMfn=62, mainMfn=7229, sourceMaxMfn=7230, targetMaxMfn=63; merge-gbl-newmfn-alt-autoin-flc подтвердил autoin/ФЛК для побочной записи в ARCH: tool=0.045231s, native=0.006041s, sideAutoin=1, sideFlcRejected=1. Full-size benchmark выполняется tools/DP_Irbis64NativeImportRecordsBenchmark.php на копиях RPC: последний точечный запуск RPC merge-gbl-newrec импортировал 95 899 ISO-записей и создал 95 899 побочных записей; irbistool=82.921497s, native 114.512541s, mergeGblApplied=95899, mergeGblCreatedRecords=95899, mergeGblCreatedRecordDetailsTotal=95899, mergeGblCreatedRecordDetailsOmitted=94899, errors=0, порядок MFN side -> main подтвержден на контрольных парах. Более простые сценарии на RPC: append irbistool=14.721969s, native 15.934656s; CheckCoding=true irbistool=14.741732s, native 17.069861s; UseAutoin=true irbistool=18.244962s, native 17.257069s; простой MergeGbl irbistool=17.579352s, native 17.735132s, mergeGblApplied=95899. Runtime upload+queue smoke дополнительно проверен задачей 506589 на IBIS3: загружен текстовый файл 55 байт, импортирована 1 запись, задача завершилась с progress=1.

Для проверки используется tools/DP_Irbis64NativeExportRecordsCompare.php. Скрипт создает изолированную копию IBIS, запускает irbistool.exe export для диапазона -mf 1 -mt 5, списка -l <file>, поисковой выборки -se "K=ANDROID", сложной boolean-выборки -se "K=ANDROID" + "K=JAVA", координатных выборок -se "K=ANDROID" (G) "K=ПРОГРАММИРОВАНИЕ" и -se "K=ANDROID" (F) "K=ПРОГРАММИРОВАНИЕ", последовательного поиска -sc "p(v700)", фильтра -flt с PFT if p(v700) then '1' fi, FST-преобразования -t с FST 200 0 v200, @included + 200 0 v200 при наличии included.fst, 200 0 v200 + 0 0 '*', PRMarc FST и реальными BUS2.FST, QueryToRec.fst, BUSU.FST из IBIS, ISO, текстового формата и -hdr, выполняет native-экспорт и сравнивает выходные файлы побайтно для UTF-8 и -win. Скрипт также проверяет монотонные вызовы progress callback. Runtime-проверка дополнительно подтверждает upload FST через Database/UploadExportFst, перенос export.fst в каталог результата, прямой запуск с реальной BUS2.FST, queue smoke 506577 с progress=1 и скачивание итогового records.iso. Массовая проверка cleanup выполняется отдельным tools/DatabaseExportRecordsCleanupSelfTest.php в изолированном tools/tmp: тестирует CleanupMaxRuns, CleanupRetentionDays, сохранение _uploads и пропуск невалидных имен каталогов.

Для SearchExpression с квалификатором поля, например K=ANDROID/1200 или K=II/1200, ИРБИС 128 использует полноценный provider-level поиск и экспортирует найденные записи. Текущий irbistool.exe для того же export -se "K=ANDROID/1200" на тестовой копии IBIS возвращает found: 0 и пустой файл, хотя native search на той же БД находит 5 MFN. На большой копии RPC (MAXMFN=95899) сценарий export -se "K=II/1200" дал native-результат 380 записей, 360109 байт, SHA1 b7ddde18465661b17e539a14422047f27dcd26e3, native wall-clock 0.018332 с и peak memory 6291456, а текущий irbistool.exe снова вернул found: 0 и пустой файл. Это зафиксировано как дефект irbistool, а не как целевое поведение: Database/ExportRecords не эмулирует пустой результат утилиты.

Для непустого near-выражения A=$ $ A=$ ИРБИС 128 также не повторяет ошибочную пустую выдачу irbistool. На копии RPC native search/export возвращает 80037 записей, 73678991 байт, SHA1 d65a8763c23851d2942b73ef277c9b3f9cb5b74f; прямой irbistool.exe export -se "A=$ $ A=$" на той же копии печатает OpenDB MORPH -400, found: 0 и создает пустой файл. Это документируется как дефект утилиты. Same-term near, включая цепочки вроде A=$ $ A=$ $ A=$, обрабатывается через BitList без загрузки координатных postings; цепочный сценарий сверяется с irbistool побайтно. Для более сложных непустых distance-сценариев остается требование дальнейшей streaming/batched оптимизации на очень больших БД.

Непустой dot/near-поиск также проверяется на реальных full-size сценариях: K=ABRISS . K=ABRISSE и K=ABRISS $ K=ABRISSE на копии RPC экспортируют две записи, 1706 байт, SHA1 330c7b1a4e810acd5db7063e1f1b6a48e5a3028a, и совпадают с irbistool побайтно. Широкие и сложные dot/near-выражения остаются отдельным направлением оптимизации.

Для широкого same-term dot K=$ . K=$ ИРБИС 128 использует потоковый поиск соседних позиций и не загружает postings целиком в память. На копии RPC native-экспорт возвращает все 95899 записей и SHA1 полного ISO bf27c5dd78576d75e784e914e192baef0183364c; текущий irbistool.exe для того же выражения печатает found: 0 и создает пустой файл, что документируется как дефект утилиты.

Для широкого same-term near K=$ $ K=$ native-поиск также возвращает все 95899 записей без загрузки postings в память. Текущий irbistool.exe для этого выражения также печатает found: 0; ИРБИС 128 это ошибочное поведение не эмулирует.

Для широких выражений с разными термами, например K=A$ . K=AB$, K=A$ $ K=AB$, K=A$ . K=AB$ . K=B$ и K=A$ $ K=AB$ $ K=B$, поиск выполняется пакетно: postings потоково раскладываются во временные bucket-файлы по MFN, затем каждый bucket сравнивается отдельно. Это позволяет проверять координаты tag/occ/cnt без загрузки всего словаря, IFP или полного списка postings в оперативную память. Временные каталоги создаются во временной папке процесса и удаляются после завершения операции.

Цепочки . и $ с несколькими термами проверяются как единое multi-term выражение: для . учитывается порядок терминов и позиционный сдвиг, для $ - общее окно близости внутри одного mfn/tag/occ. Текущий irbistool.exe export -se для broad-chain выражений вида K=A$ . K=AB$ . K=B$ и K=A$ $ K=AB$ $ K=B$ на контрольной копии RPC возвращает результат, совпадающий с более коротким K=A$ $ K=AB$, то есть схлопывает цепочку. Это зафиксировано как дефект утилиты; Database/ExportRecords выполняет полную проверку цепочки и не повторяет это поведение.

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

Для больших БД проверку производительности нужно выполнять на отдельном full-size стенде. Операция должна оставаться потоковой: нельзя читать весь MST, XRF, список записей или выходной ISO-файл в оперативную память.