Django: sqlite для dev, mysql для напоминания? [закрытый]
4 ответа
Обновление 2014-Jun-27 :
RFC 7231, протокол передачи гипертекста (HTTP/1.1): Semantics and Content , был опубликован как ПРЕДЛАГАЕМЫЙ СТАНДАРТ. Из Changelog :
Синтаксис поля заголовка Location был изменен, чтобы разрешить все Ссылки URI, включая относительные ссылки и фрагменты, вдоль с некоторыми пояснениями относительно того, когда использование фрагментов не будет соответствующие. (Раздел 7.1.2)
Важные точки из раздела 7.1.2. Местоположение :
Если в ответе 3xx (перенаправление) указано значение местоположения не имеют компонент фрагмента, агент пользователя ДОЛЖЕН обработать перенаправление, как если бы значение наследовало компонент фрагмента URI ссылка, используемая для генерации целевого объекта запроса (т.е. перенаправление) наследует фрагмент исходной ссылки, если таковой имеется).
Например, Запрос GET, сгенерированный для ссылки URI « http://www.example.org/~tim » может привести к 303 (см. раздел «Другое») ответ, содержащий поле заголовка:
Местоположение :/People.html # tim, который предполагает, что агент пользователя перенаправляет на « http://www.example.org/People.html#tim »
Аналогично, запрос GET сгенерирован для ссылки URI « http://www.example.org/index.html#larry » может привести к 301 (Moved Постоянно) ответ, содержащий поле заголовка:
Местоположение: http://www.example.net/index.html, который предполагает, что агент пользователя перенаправляет на « http://www.example.net/index.html#larry », сохраняя оригинал идентификатор фрагмента.
Это должно ясно ответить на ваши вопросы.
Update END
это открытая (не указанная) проблема с текущей спецификацией HTTP . он рассматривается во 2 выпусках рабочей группы IETF httpbis :
- # 6: Фрагменты, разрешенные в расположении
- # 43: Комбинация/приоритет фрагментов во время перенаправлений
# 6 позволяет использовать фрагменты в заголовке Местоположение . # 43 говорит об этом:
Я только что протестировал это с различными браузерами.
- Firefox и Safari используют фрагмент в заголовке местоположения.
- Opera использует фрагмент из исходного URI при наличии, в противном случае фрагмент из местоположения перенаправления
- IE (8) игнорирует фрагмент в URI расположения, таким образом, будет использовать фрагмент из исходного URI при наличии
Предложение:
"Примечание: поведение, когда идентификаторы фрагментов из исходного URI и перенаправление должны быть объединены текущие агенты пользователя действительно отличаются от того, какой фрагмент имеет приоритет ".
[...]
Похоже, что IE8 использует идентификатор фрагмента из
Location(поведение, которое я видел, может быть ограничено localhost).Таким образом, у нас, похоже, есть последовательное поведение для Safari/IE/Firefox/Chrome (только что протестировано), в том, что фрагмент из заголовка Location используется, независимо от того, каким был исходный URI.
Поэтому я изменяю свое предложение, чтобы документировать это как ожидаемое поведение.
это приводит к наиболее совместимому с браузером и будущему подтверждению (поскольку эта проблема в конечном итоге будет стандартизирована) ответа на ваш вопрос:
A: фрагменты из исходных URL-адресов будут отброшены.
B: фрагменты из заголовка Location .
Короче говоря, нет; если вы не хотите излишне удвоить время разработки.
-121--2128166-Я настоятельно рекомендую использовать тот же бэкэнд базы данных в производстве, что и при разработке, и все этапы между ними. Джанго будет абстрагировать данные базы данных, но наличие различных сред оставит вас открытыми для ужасной интернационализации, проблем конфигурации и неприятных крошечных несоответствий, которые даже не появятся, пока вы не заставите его жить.
Лично я бы придерживался mysql, но никогда не сталкивался с postgres:)
Я поддерживаю все предыдущие ответы, добавляя некоторые явные причины:
- MySQL выдает Warning exception, когда вы пытаетесь сохранить строку длиннее ширины поля - вы не получите их в SQLite, поэтому не только ваша строка будет отличаться между dev и production, но и поведение программы
- ошибки в обоих бэкендах разные - я помню, что однажды я пробовал SQLite для dev и MySQL для production, но оказалось, что я обнаружил ошибку в MySQL бэкенде, которой не было в SQLite. Поэтому я подал тикет на него и перешел на MySQL для тестирования :-)
И вы даже можете попробовать посоревноваться с SQLite в скорости, посмотрите мой ответ на другой вопрос:
Зачем вам это нужно?
- SQLite пока не поддерживает хранимые процедуры.
- SQLite бестиповый . При запуске MySQL вы можете столкнуться с множеством проблем с приведением типов.
- Также SQLite еще не поддерживает ПРАВИЛЬНОЕ соединение.
Короче говоря, нет; если только вы не хотите неоправданно удвоить время разработки.