48 lines
3.0 KiB
Markdown
48 lines
3.0 KiB
Markdown
# Запрос 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). Приоритет: не сломать существующее поведение.
|