Текущая транслитерация географических названий очень похожа на беларусский латинский алфавит (где lł вмето ĺl), которому лет так 100. До этого использовался польский алфавит. Причём варианты латинки и польского алфавита использовались в переписке и издательстве, что в теории должно упоминаться в школьном курсе истории и возможно литературы.
как graphql помогает в решении делать join или подзапросы?
как позволяет избежать большого количества join или избегает бамбёжки самыми толстыми запросами?
как позволяет ограничить условие выборки и сортировки, чтобы попасть в индэкс?
Встречались, поэтому и сделали карманное окружение, где такой проблемы нет
То есть в основном не нужно чтобы быстро поднятое окружение покрывало все части сервиса, я так понимаю в этом случае 3th party api либо просто мокаются, либо настраиваются ручками?
Понравилось (кроме монорепы), прямо несколько вопросов собралось:
Думал увидеть шаги, которые начинаются до написания кода или берётся тикет и в бой?
Для тэстовых окружений не встречались с проблемой многих желающих на одно окружение?
Расскажите про дальнейшую судьбу для отключаемой функциональности, тк если не чистить, то я себе представляют скатывание в if лапшу, если чистить всё, то встаёт вопрос о скорости решения отложенных деградаций?
Также интересует подход к обеспечению обратной совместимости или получается никогда таких изменений не вносить вообще?
Как накатывается миграция на prestable и stable, то есть это отдельные базы или миграция сразу для обоих применяется?
Единственный момент, там нет параметров, если при разных параметрах запрос может быть как быстрым, так и медленным, то во первых может немного сказываться на статистике, во вторых с логом проще сразу в explain перейти.
if 'CREATE INDEX' in sql:
sql = sql.replace('CREATE INDEX', 'CREATE INDEX CONCURRENTLY')
хак, я привёл пример при которых можно получить не совсем то, чего хотелось.
Одно дело парсинг логов, который можно перезапустить (источник вряд ли меняется), другое дело потенциальное изменение результирующих данных в базе как сайд эффект.
обратите внимание как django использует DEFAULT — только для заполнения таблицы значениями, после этого DEFAULT удаляется, но если не тушить машинки с django, то после миграции могут быть вставки старым кодом и DEFAULT просто не сработает пока не обновится код на всех машинках с django
как поведёт себя RunSql("UPDATE table SET sql = 'CREATE INDEX' WHERE sql = 'CREATE INDEX CONCURRENTLY'")
обходит ли библиотека описаные проблемы с SET NOT NULL и RENAME COLUMN
что будет с CREATE COLUMN SET DEFAULT NOT NULL когда мы раскатываем миграцию для кластера из нескольких инстансов с django (то есть старый/новый код работает со новой/старой схемой)?
Тогда возникает вопрос насколько хорошо он работает с мультипроцессорными приложениями и воркерами, запускаемыми либо по крону, либо по событиям в rabbit/kafka? Нужно ли ему говорить ручками, что появилась новая машина или есть механизм autodiscovery?
Минимум на чём пробовал — postgres 9.4, более старые чесно говоря не смотрел. Не подскажите на какой версии это не работает?
На 9.4+ если с таблицей никто не работает, то можно считать операцию безопасной, иначе зачем удалять. Если с колонкой никто не работает, то тоже можно считать безопасной, так как отрабатывает мгновенно, согласно документации www.postgresql.org/docs/current/static/sql-altertable.html колонка не удаляется физически, а помечается удалённй, потом место будет очищено через AUTO VACUUM.
При удалении таблицы/колонки все машинки сперва перестают работать с таблицей/колонкой, только потом накатывается миграция, назвал это обратным порядок выкатки в тексте.
Правильный порядок таблиц задан жёстко или есть логика которая может раскручивать зависимости каскадно? Потому что если схама часто меняется, то можно наткнуться, хотя конечно это сразу можно словить ролбэком транзакции и подправить.
Существуют ли внешние ссылки на данные в базе (например мыло или другие ключи), я так понимаю когда происходит перенос, то кто-то внешний знает где лежит конкретный ключик?
как graphql помогает в решении делать join или подзапросы?
как позволяет избежать большого количества join или избегает бамбёжки самыми толстыми запросами?
как позволяет ограничить условие выборки и сортировки, чтобы попасть в индэкс?
То есть в основном не нужно чтобы быстро поднятое окружение покрывало все части сервиса, я так понимаю в этом случае 3th party api либо просто мокаются, либо настраиваются ручками?
Думал увидеть шаги, которые начинаются до написания кода или берётся тикет и в бой?
Для тэстовых окружений не встречались с проблемой многих желающих на одно окружение?
Расскажите про дальнейшую судьбу для отключаемой функциональности, тк если не чистить, то я себе представляют скатывание в if лапшу, если чистить всё, то встаёт вопрос о скорости решения отложенных деградаций?
Также интересует подход к обеспечению обратной совместимости или получается никогда таких изменений не вносить вообще?
Как накатывается миграция на prestable и stable, то есть это отдельные базы или миграция сразу для обоих применяется?
я бы лучше подумал над охлождением на такой глубине
</зануда>
pyflameна каждой отдельной машинке собираете или есть механизм централизованого сбора в одном месте c ротацией?Позволю себе предположить, что:
Одно дело парсинг логов, который можно перезапустить (источник вряд ли меняется), другое дело потенциальное изменение результирующих данных в базе как сайд эффект.
обратите внимание как django использует
DEFAULT— только для заполнения таблицы значениями, после этогоDEFAULTудаляется, но если не тушить машинки с django, то после миграции могут быть вставки старым кодом иDEFAULTпросто не сработает пока не обновится код на всех машинках с djangoОчень похоже на то, что я писал https://habr.com/post/425063/ + библиотечка https://github.com/tbicr/django-pg-zero-downtime-migrations
Было пару вопросов к библиотеке:
RunSql("UPDATE table SET sql = 'CREATE INDEX' WHERE sql = 'CREATE INDEX CONCURRENTLY'")SET NOT NULLиRENAME COLUMNCREATE COLUMN SET DEFAULT NOT NULLкогда мы раскатываем миграцию для кластера из нескольких инстансов с django (то есть старый/новый код работает со новой/старой схемой)?На 9.4+ если с таблицей никто не работает, то можно считать операцию безопасной, иначе зачем удалять. Если с колонкой никто не работает, то тоже можно считать безопасной, так как отрабатывает мгновенно, согласно документации www.postgresql.org/docs/current/static/sql-altertable.html колонка не удаляется физически, а помечается удалённй, потом место будет очищено через AUTO VACUUM.
При удалении таблицы/колонки все машинки сперва перестают работать с таблицей/колонкой, только потом накатывается миграция, назвал это обратным порядок выкатки в тексте.
Есть похожий опыт, кратко резюмируя:
Существуют ли внешние ссылки на данные в базе (например мыло или другие ключи), я так понимаю когда происходит перенос, то кто-то внешний знает где лежит конкретный ключик?
Можете подсказать что такое `шарпей` :)?