docs: запрос Opus — дедупликация документов и позиций
This commit is contained in:
@@ -0,0 +1,47 @@
|
||||
# Запрос Opus — логика дедупликации в пайплайне
|
||||
|
||||
Дата: 28.06.2026
|
||||
|
||||
## Проблема
|
||||
|
||||
Сейчас:
|
||||
|
||||
1. **Загрузка:** дубликат файла определяется только по имени (`filename`). Тот же файл с другим именем → новый документ.
|
||||
2. **Сравнение (ADD):** при добавлении строки в `spec_current` не проверяется `name_hash`. Одна и та же услуга добавится дважды если пришла из двух разных допников с одинаковым содержанием.
|
||||
3. **Позиции:** `name_hash = md5(нормализованное_имя || date_start)`. Хеш есть, но используется только для UPDATE (поиск target_hash). При ADD — не проверяется.
|
||||
|
||||
## Вопросы
|
||||
|
||||
### 1. Дедупликация документов при загрузке
|
||||
|
||||
Сейчас: `delete_by_document(contract_id, filename)` — только по совпадению имени.
|
||||
|
||||
**Нужно ли:**
|
||||
- Сравнивать по хешу содержимого (sha256 original_bytes)?
|
||||
- Сравнивать по `elements_json`?
|
||||
- Или только по имени + предупреждение?
|
||||
|
||||
### 2. Дедупликация строк в spec_current (ADD → UPSERT)
|
||||
|
||||
Сейчас: ADD всегда INSERT. Если та же услуга приходит из другого допника — будет дубликат.
|
||||
|
||||
**Предложение:** перед INSERT проверять `name_hash`:
|
||||
```
|
||||
есть name_hash? → UPDATE (как обычный UPDATE)
|
||||
нет → INSERT
|
||||
```
|
||||
|
||||
**Вопросы:**
|
||||
- Правильно ли это? В каких случаях ADD должен ОСТАТЬСЯ INSERT даже при совпадении name_hash?
|
||||
- Как обрабатывать если ADD и UPDATE приходят в одном наборе ops и пересекаются по name_hash?
|
||||
|
||||
### 3. Связанные краевые случаи
|
||||
|
||||
- Два допника с одинаковым содержанием, разные имена → сейчас: две обработки, возможны дубликаты. Как надо?
|
||||
- Один допник добавляет услугу X, другой её же удаляет. Порядок имеет значение? Как обеспечить?
|
||||
- ZIP содержит файлы с теми же именами что уже загружены. Перезаписывать? Пропускать? Спрашивать?
|
||||
- Два одинаковых договора (разные имена) в одном батче. Как группировать?
|
||||
|
||||
## Ожидаемый ответ
|
||||
|
||||
На каждый сценарий: **как ДОЛЖНО быть** и **как проще всего реализовать сейчас** (MVP). Приоритет: не сломать существующее поведение.
|
||||
Reference in New Issue
Block a user