Рассмотрим этот упрощенный сценарий.Таблицы основных данных:
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
во время нормализации, поскольку это правило валидации, а не нормализации.
Я продолжаю бить стену.Как правильно написать схему проверки в этом случае?