Утверждение дочерней таблицы в Цербере

Question

Рассмотрим этот упрощенный сценарий. Мастер-таблицы:

CREATE TABLE queue (
    id bigint PRIMARY KEY,
    num text NOT NULL UNIQUE
);

CREATE TABLE queue_device (
    id bigint PRIMARY KEY,
    queue_id bigint NOT NULL REFERENCES queue ON DELETE CASCADE,
    device text NOT NULL,
    UNIQUE (queue_id,device)
);

При добавлении устройств пользователи, очевидно, не знают id, Они вошли num вместо. Итак, я попробовал эту схему проверки:

SCHEMA = {
    'queue': {
        'type': 'string',
        'empty': False,
        'required': True,
        'rename': 'queue_id',
        'coerce': 'queue_id'
    },
    'device': {
        'type': 'string',
        'empty': False,
        'required': True
    }
}

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

ОК, поэтому я попытался установить coercer на переименованном поле, отмечая его readonly потому что пользователи не должны устанавливать его напрямую.

SCHEMA = {
    'queue': {
        'type': 'string',
        'empty': False,
        'required': True,
        'rename': 'queue_id'
    },
    'device': {
        'type': 'string',
        'empty': False,
        'required': True
    },
    'queue_id': {
        'readonly': True,
        'coerce': 'queue_id'
    }
}

Сначала я проверяю, потом нормализую.

if not validator.validate(document, normalize=False):
    raise ValidationError('Document validation failed.', validator.errors)
document = validator.normalized(document)

Это не из-за readonly править. Опять же, мне интересно, что является обоснованием для проверки readonly во время нормализации, так как это валидация, а не нормализация.

Я продолжаю бить стену. Как правильно написать схему проверки в этом случае?