Как проверить несколько сущностей на самих себя, а также на существующие строки в базе данных?

Логически вы можете сохранять только один объект за раз, не только на уровне приложения, но и на уровне СУБД, поэтому правило правильно говорит вам, что данные недействительны, поскольку оно проверяет только один объект за раз.

Я думаю, вам нужно либо какое-то состояние, чтобы справиться с этим, либо вам понадобится какое-то сочетание того, для чего предназначены правила проверки и приложения, т.е. вам нужно будет проверять данные без состояния, а также данные с состоянием/сохраняемые , не только все часы в несохраняемом наборе данных должны быть действительными по отношению друг к другу, они также должны быть действительными по отношению к уже сохраненным данным в базе данных.

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

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

Вот пример — я не знаю вашу настройку ассоциации, поэтому я просто предполагаю, что вы сохраняете Stores с ассоциированным BusinessHours, хотя точная настройка не имеет большого значения, она должна просто показать, как создавать и передавать пользовательские параметры:

// ...
$store = $this->Stores->patchEntity($store, $this->request->getData());
$businessHourIds = new \ArrayObject(
    collection($store->business_hours)
        ->extract('id')
        ->filter()
        ->indexBy(function ($value) {
            return $value;
        })
        ->toArray()
);
// $businessHourIds would represent an array like this, where both
// the key and the value would hold the ID: [1 => 1, 2 => 2, 3 => 3, ...]
if ($this->Stores->save($sore, ['businessHourIds' => $businessHourIds])) {
    // ...
}
// ...

Важно, чтобы это был экземпляр ArrayObject, чтобы его состояние сохранялось при множестве различных вызовов save() для каждого объекта рабочего часа. Затем ваше правило может сделать что-то вроде этого:

function (BusinessHour $entity, array $options): bool {
    if (!isset($options['businessHourIds'])) {
        return false;
    }
    
    // If the entity isn't new, its ID must be present in the IDs list
    // so that it can be excluded in the exists check
    if (
        !$entity->isNew() &&
        !isset($options['businessHourIds'][$entity->id]
    ) {
        return false;
    }

    // the current entries opening time must be smaller than its closing time
    if ($entity->opening_time >= $entity->closing_time) {
        return false;
    }

    $conditions = [
        'id NOT IN' => (array)$options['businessHourIds'],
        'store_id' => $entity->store_id,
        'day' => $entity->day,
        'closing_time >' => $entity->opening_time,
        'opening_time <' => $entity->closing_time,
    ];
    
    // remove the current entity ID from the list, so that for the next
    // check it is not being excluded, meaning that all following business
    // hours will have to be valid according to this entity's data
    unset($options['businessHourIds'][$entity->id]);

    return !$options['repository']->exists($conditions);
}

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