Как большие сайты обрабатывают немедленные изменения схемы при использовании Django? - PullRequest
0 голосов
/ 23 сентября 2010

Я использую south, но мне очень не хочется снова переносить данные вручную, даже если я сделаю одно маленькое крошечное обновление класса. Если я не использую django, я легко могу изменить схему таблицы и внести коррективы в класс, и я в порядке.

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

Есть ли какой-то продвинутый метод, который используют люди, возможно, даже модифицирующий ядро ​​самого Django? Или есть что-то в south, что я не просто ворчу?

1 Ответ

1 голос
/ 24 сентября 2010

Мне очень не хочется снова переносить данные вручную, даже если я сделаю одно маленькое крошечное обновление для класса.

Можете ли вы указать, какие именно обновления?Если вы имеете в виду добавление новых полей или редактирование существующих, то, очевидно, да.Если вы имеете в виду изменение методов, которые работают с полями, то нет необходимости мигрировать.

Я знаю, что большинство людей, вероятно, сказали бы мне, чтобы я правильно продумал схему заранее, заранее

Это, безусловно, поможет обдумать это пару раз.Опыт тоже помогает.Но, очевидно, вы не можете предвидеть все.

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

Честно говоря, я не убежден этим аргументом.Если изменения могут быть развернуты «немедленно» с использованием SQL, то я бы поспорил, что они могут быть также развернуты с использованием South.Особенно, если вы автоматизировали развертывание с использованием Fabric или чего-то подобного.

Также мне трудно поверить, что время, затрачиваемое на выполнение миграции с использованием сгенерированного сценария, может быть значительно больше, чем время, затрачиваемое на первую запись соответствующего SQL, а затем на его выполнение.По крайней мере, это не так в моем опыте.

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

Или на юге есть что-то такое, что я не просто лачу?

Я подозреваю, что вы не впадаете в мысль о том, чтобы иметь упорядоченную, управляемую версией, обратимуюмиграции.Миграции только на SQL не всегда рассчитаны на обратимость (я знаю, что есть исключения).И они не являются упорядоченными, если разработчики не позаботятся о том, чтобы их сохранить.Я даже видел, как люди запускают потенциально проблемные обновления на производстве, даже не останавливаясь, чтобы сначала запустить транзакцию, а затем отменить SQL, даже не делая записи об этом.

Я не подвергаю сомнению ваши навыки или внимание к деталям здесь;Я просто указываю на то, что, по-моему, является вашим разрывом с Югом.

Надеюсь, это поможет.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...