2016-03-27 4 views
0

Можно ли хранить поле кортежей Model в Django? В моем случае у меня есть модель Переводчик. Переводчик должен хранить информацию о том, на каких языках он может переводить. Но может быть ситуация, когда переводчик не может переводить с английского на немецкий, но он может сделать это в противоположном направлении.Как сохранить список кортежей в модели Django?

Так один объект переводчик может хранить это:

  • с немецкого на английский
  • с голландского на английский

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

Так что я, вероятно, ищу, чтобы хранить поле кортежей моделей (есть модель под названием Язык).

+0

Зачем вам нужно хранить кортеж, когда вы можете просто сохранить несколько столбцов? From-lan to-lan from-str to-str – dkarchmer

+0

Или посмотрите на травление или используя JSONField. https://pypi.python.org/pypi/django-picklefield и https://github.com/bradjasper/django-jsonfield –

ответ

3

Решение, которое я рекомендую, было бы создать модель для представления каждого одностороннего перевода, а затем использовать связь ManyToManyField.

Например:

class LanguagePair(models.Model): 
    from_language = models.CharField(max_length=220) 
    to_language = models.CharField(max_length=220) 

class Translator(models.Model): 
    languages = models.ManyToManyField('LanguagePair') 
    ... 

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

Это позволит вам легко запросить всех переводчиков, которые могут переводить определенный язык, поскольку фактический перевод является объектом. Я бы также рекомендовал, чтобы вместо этого в качестве хранения языков в CharField с вы на самом деле сделали еще одну модель Language и изменили модель LanguagePair на наличие двух полей ForeignKey.

Альтернативным решением будет сериализация пар списка или языков из стандартного списка python и сохранение его как строки JSON в CharField, но это затруднит выполнение запросов и может стать проблемой в будущем. Как правило, неплохо не бояться разделить логику на отдельные модели, поскольку это приводит к более гибкому и масштабируемому подходу.

+0

Спасибо, это, вероятно, хорошее решение, но я хотел сделать его максимально простым. Я выбираю этот путь. Еще один вопрос: почему вы помещаете LanguagePair в строку вместо класса строк? –

+0

Просто привычка ... Если вы используете строку, она может ссылаться на модель, которая определена после нее, и вы также можете ссылаться на модели из других приложений, не импортируя их так: «app.LanguagePair». Но в этом примере вы правы, и это было необязательно. Я бы также сказал, что это * самое простое решение, оно позволяет вам искать, не расшифровывая ничего и улучшая производительность. Это также более гибко, если вам когда-либо понадобится сделать что-то более сложное в будущем. – joshcarllewis

Смежные вопросы