Утверждение дочерней таблицы в Цербере - PullRequest
0 голосов
/ 27 октября 2018

Рассмотрим этот упрощенный сценарий.Таблицы основных данных:

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 во время нормализации, поскольку это правило валидации, а не нормализации.

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

...