Bitrix D7 ORM: как узнать ID существующей записи?

Question

[ragnar_ok]

Создал сущность BookTable. Добавил UniqueValidator для поля NAME. Теперь в случае, если обнаруживается дубликат, то запись не добавляется, а Result::isSuccess возвращает false.

class BookTable extends DataManager
{
    public static function getMap()
    {
        return [
            new Fields\IntegerField('ID', [
                'primary' => true,
                'autocomplete' => true,
            ]),
            new Fields\TextField('NAME', [
                'validation' => function() {
                    return [
                        new Fields\Validators\UniqueValidator('Not unique'),
                    ];
                }
            ]),
        ];
    }
}

Как в случае обнаружения дубликата получить ID уже существующей записи с этим NAME?
Сейчас я использую BookTable::getRow с фильтром по NAME в случае, если обнаружился дубликат.

$result = BookTable::add([
    'NAME' => 'NAME',
]);

if ($result->isSuccess()) {
    $result->getId();
} else {
    BookTable::getRow(['select' => ['ID'], 'filter' => ['NAME' => 'NAME']])['ID']; //  Приходится делать дополнительный запрос
}

Адекватно ли это решение?

Answer 1

[Александр Маджугин]

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

Кстати если добавление идет не в цикле, а вероятность дублей у вас больше 50% (даже возможно 40%) то лучшим решением будет сначала проверить нет ли уже записи с таким именем и только потому выполнять добавление, если ее нет.

Comments

[ragnar_ok]

достать одним запросом

Ага, понял. Собрать в массив и использовать один раз getList.

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

То есть написать свой валидатор? Что вы имеете в виду? Почему UniqueValidator не подходит?

[Александр Маджугин]

ragnar_ok, подходит конечно! Однако в описанном случае, когда вероятность возникновения дублей очень высока - большей 50% - такой свой валидатор будет работать быстрее.

Ну смотрите - пусть цена записи c предварительной валидацией N попугаев, а цена получения id по имени K попугаев. При этом мы можем предположить что N >= K, поскольку N содержит в валидаторе тот же поиск по NAME что и K.

Тогда, при вероятности возникновения дублей 60%, вариант где вы сначала пробуете записать, а потом получаете id по имени будет стоить N+0.6K, а вариант когда вы сначала проверяете, а потом записываете если нет id будет стоить K+0.4N. Помня про то что N>=K, N можно представить в виде K+m.
Следовательно вариант 1 будет равен 1.6K+m, а вариант 2 - 1.4K+m
Очевидно что 1.6K+m > 1.4К+m

Answer 2

[eugenezadorin]

Адекватно, если это единичная операция добавления - например если это отправка формы.

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

Comments

[ragnar_ok]

Можно, пожалуйста, поподробнее про справочник? Что вы имеете в виду?

[eugenezadorin]

Массив в памяти. Ключ - название книги, значение - её ID.

Формировать этот массив до начала основной обработки, с помощью BookTable::getList

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

Но повторюсь, тут все зависит от конкретной ситуации. Александр Маджугин ниже тоже нормальное решение предложил