Можно ли увеличить ограничение имени идентификатора в PostgreSQL до более чем 63 символов без перекомпиляции всей системы базы данных? У меня есть этот проект Django, генерирующий повторяющиеся имена индексов из-за этого ограничения, и нет возможности изменить имена моделей из-за бизнес-требований моего проекта.
Поднимите NAMEDATALEN PostgreSQL без перекомпиляции
Ответы:
Для меня это звучит как ошибка Django. Ранее исправлена ошибка максимальная длина имени, не указанная для PostgreSQL. Я ожидаю, что Django сгенерирует идентификаторы базы данных, соответствующие max_name_length(). Возможно, я безосновательно оптимистичен.
Django уже знает, как усекать и добавлять повторяющийся хеш, чтобы соответствовать max_name_length() Oracle. (См. Проблемы с именами). , составной идентификатор и надейтесь на лучшее, если вы используете любую другую платформу.
Возможно ли, что вы где-то переопределяете поведение по умолчанию, из-за чего Django игнорирует max_name_length()?
Позже . . .
На самом деле они просто составляют длинный составной идентификатор и надеются на лучшее. Тема на osdir.com предполагает, что это будет исправлено в Django 1.3. См. раздел Проблемы с DatabaseCreation, именами таблиц и именами индексов — msg#00142 а>
Еще позже. . .
Билет ошибки длины индекса при выполнении тестов в MySQL показывает, что то же исправление для MySQL было исправлено в версии 1.2. . Также у PostgreSQL (и, возможно, у любой другой платформы) была такая же проблема. Я не знаю, вошло ли исправление для PostgreSQL в версию 1.2.
Нет, нельзя, вы должны использовать более короткие имена. Другие СУБД допускают еще меньше символов, вам всегда нужно проверять эти ограничения.
TOP
или LIMIT
, использование EXTRACT
или DATEPART()
, разделение идентификаторов одинарными, двойными кавычками или скобками, а также максимальная длина идентификатора 63 или 30. . Люди частично используют фреймворки, чтобы перестать думать о серверной части и сосредоточиться на разработке приложений. 24.02.2011