Как лучше всего добавить временную информацию в модель Django? (без создания новой модели)

Question 1

Лучший способ понять мой вопрос - использовать код:

class ToDoList(TimeStampedModel):
    DEFAULT_THEME = 1

    name = models.CharField(max_length=32)
    ... # other fields
    STATUS_CHOICES = (
        ('C', 'CREATED'),
        ('R', 'READY'),
        ('V', 'VALIDATED')
    )
    status = models.CharField(max_length=1, choices=STATUS_CHOICES, default='C')

Есть несколько типов пользователей

Создатели: кто может создать ToDoList и запросить подтверждение
Валидаторы: кто может проверять список

Теперь, когда валидатор отклоняет запрос проверки, он также должен указать причину. Это, вероятно, произойдет не более чем в 10% всех случаев, поэтому я не хочу добавлять поле rejection_reason в мою модель ToDoList.

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

Не знаю, поможет ли это, но для API я использую django-rest-framework.

Спасибо.

ОБНОВЛЕНИЕ

После того, как валидатор отклоняет список, он должен указать причину, чтобы создатель мог изменить все, что не так со списком. После внесения изменений Создатель снова запрашивает подтверждение. Цикл продолжается до тех пор, пока Валидатор не примет ToDoList. В этот момент причина отказа больше не нужна, поэтому ее можно удалить.

Итак, в конце концов, причина отклонения больше не будет существовать, и я не думаю, что нормально (с точки зрения пространства БД) иметь поле, которое будет использоваться только временно.

python django django-models

0

AdelaN 12 Авг 2014 в 20:52

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

–

petkostas

12 Авг 2014 в 20:55

Спасибо за ваш ответ, но меня беспокоит не то, как я могу скрыть / показать поле, а пространство базы данных. Кроме того, я забыл упомянуть, что после того, как ToDoList станет проверенным, причина отклонения больше не имеет значения (он будет удален). Поэтому я не думаю, что стоит иметь поле в 1000 символов, которое будет использоваться так редко ...

–

AdelaN

12 Авг 2014 в 21:05

Вы хотите использовать отказ для чего-то в виде электронного письма? предоставьте эту информацию (чтобы не запутать людей, отвечающих) в своем вопросе, если да, то да, она вам определенно не нужна, используйте только поле формы, манипулируйте данными после проверки формы, а в конце запроса она исчезнет.

–

petkostas

12 Авг 2014 в 21:08

Я обновил свой вопрос :) Надеюсь, теперь все понятно.

–

AdelaN

12 Авг 2014 в 21:18

1

С обновлением я не вижу способа избежать db (поскольку из вашего описания я понимаю, что это сохраняется до тех пор, пока создатель не запросит повторную проверку, то, что вы не можете предсказать, когда это произойдет), но затем снова сколько записей и какой объем трафика мы говорим, чтобы это помешало вашему потоку? В конце концов, вы можете удалить запись о причине после завершения процесса.

–

petkostas

12 Авг 2014 в 21:23

Answer

Вы излишне беспокоитесь о сохранении (предположительно) небольшого количества текста вместе с вашим ToDoList. Вот как я бы с этим справился, если бы цель состояла в том, чтобы не усложнять, а не добавлять еще одну модель.

class ToDoList(models.Model):
    name = models.CharField(...)
    validated_at = models.DateTimeField(..., null=True, editable=False)
    rejection_reason = models.TextFiel(..., editable=False)

Запрос на validated_at__isnull=False, чтобы получить проверенные списки задач, полностью игнорируя rejection_reason. Запросите validated_at__isnull=True, чтобы получить список непроверенных списков задач, и используйте rejection_reason, чтобы показать пользователю причину. Если вы хотите сэкономить место в своей базе данных, очистите поле rejection_reason после проверки списка дел. Вы также можете использовать filter (rejection_reason=""), чтобы сузить списки задач до тех, у которых нет причины отклонения (например, тех, которые еще не были проверены или отклонены), или exclude для того же, чтобы получить те, которые были отклонены.

1

orokusaki 12 Авг 2014 в 21:53

Ага, наверное, так я и сделаю. Почему вы предлагаете TextField вместо CharField?

–

AdelaN

12 Авг 2014 в 21:33

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

–

orokusaki

12 Авг 2014 в 21:48

Также посмотрите дополнительный бит, который я добавил в конце своего ответа.

–

orokusaki

12 Авг 2014 в 21:54

Question 2

Вы излишне беспокоитесь о сохранении (предположительно) небольшого количества текста вместе с вашим ToDoList. Вот как я бы с этим справился, если бы цель состояла в том, чтобы не усложнять, а не добавлять еще одну модель.

class ToDoList(models.Model):
    name = models.CharField(...)
    validated_at = models.DateTimeField(..., null=True, editable=False)
    rejection_reason = models.TextFiel(..., editable=False)

Запрос на validated_at__isnull=False, чтобы получить проверенные списки задач, полностью игнорируя rejection_reason. Запросите validated_at__isnull=True, чтобы получить список непроверенных списков задач, и используйте rejection_reason, чтобы показать пользователю причину. Если вы хотите сэкономить место в своей базе данных, очистите поле rejection_reason после проверки списка дел. Вы также можете использовать filter (rejection_reason=""), чтобы сузить списки задач до тех, у которых нет причины отклонения (например, тех, которые еще не были проверены или отклонены), или exclude для того же, чтобы получить те, которые были отклонены.

1

orokusaki 12 Авг 2014 в 21:53

Ага, наверное, так я и сделаю. Почему вы предлагаете TextField вместо CharField?

–

AdelaN

12 Авг 2014 в 21:33

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

–

orokusaki

12 Авг 2014 в 21:48

Также посмотрите дополнительный бит, который я добавил в конце своего ответа.

–

orokusaki

12 Авг 2014 в 21:54

Как лучше всего добавить временную информацию в модель Django? (без создания новой модели)

1 ответ

Похожие вопросы

Новые вопросы

python