Миграции: как в самой таблице хранить номер версии структуры таблицы?

Бред какой-то очередной.

Ты не поверишь https://postgrespro.ru/docs/postgresql/9.4/sql-comment.

Благодарю, то что надо.

Да, я немного не так прочел ОП. Привык что от ТС частенько дичь идет.

Само собой первым делом надо проверить а нет ли нужного в метаданных.

Если нет, то найти записвваемое место и писать туда.

О, прикольно, не знал. Спасибо.

Тебе не нужно хранить версии таблиц. Иначе можно придти к состоянию что у тебя будут разные версии разных таблиц несовместимые между собой.

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

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

Бери show create table #tablename# считай от полученной строки хэш, вот тебе версия

show create table

Ты попутал PostgreSQL и MySQL.

считай от полученной строки хэш, вот тебе версия

Получается, что версию можно узнать только после фактического создания структуры. Очень удобно программировать такое.

А как ты будешь определять версию для таблиц, которых в базе ещё нет?

А как ты будешь определять версию для таблиц, которых в базе ещё нет?

Она может быть прописана в любое время, например в инфу миграции, причем даже до запуска процедуры миграции. А с подходом как у cobold вначале пишется миграция, обязательно запускается, берется хеш структуры, и помещается в инфу о миграции.

Кроме того, нет гарантии что Postgre 9.6 даст ту же структуру, а соответственно и хеш, что и какой-нибудь Postgre 14 на той же таблице или БД. И вот тогда будет очень весело обновлять систему.

Не, хеши от лукавого.

Просто если в версии 1 ты таблицу создаешь, в версии 2 удаляешь, а в версии 3 снова создаешь. То видя отсутствте таблицы ты не знаешь на каком ты шаге.

Я бы в гите хранил DDL и таблицы не трогал. Нахрен там вообще держать всю эту метаинфу.

либо заморочиться поиском инструмента, абстрагирующего от ручного мудоханья с DDL. Но ТС обычно не ищет прямых путей.

Да, liquidbase какой-нибудь.

asdpm что? Ну костыли так костыли, я как бы ничего против не имею гита со скриптами.

Попробуй сертифицировать liquidbase под Astra Linux, открыв все исходные коды и предоставив их в сертифицирующий орган, c комментариями на русском языке, конечно же, чтобы автоматически сгенерировать документацию по коду. Года через три, после всех итераций согласований, если это, конечно, у тебя получится, можешь приходить. Боюсь только что к тому моменту эта liquidbase сильно устареет, а ты будешь прохлождаться на улице, потому что функционал liquidbase нужен был еще вчера.

Йоу, йоу, спокойно, я тебя понял.

Ну гит-то сертифицирован, я надеюсь?

жаль на жабе только)) но есть и другие, а можно и его.

а я предупреждал.. ТС иногда рычит нечленораздельно)

я с liquidbase не работал, но если я правильно помню, это херня предлагающая писать ddl очередном универсальном вендор-агностичном языке. в этой части это не просто бесполезный инструмент, от него конкретный вред, так как эта сама по себе идея абстрагирования от вендора sql-бд несостоятельна и ущербна. кроме этой токсичной и вредной идеи про абстрагирование, что еще остается в типовом инструменте этого плана? вторая ущербная несостоятельная идея об «обратных миграциях», а так какие-нибудь косяки и кривизна. у меня критика к самому классу инструментов этого плана. за вычетом нестоятельных идей, то что там остается это 0,1% кода который Xintrea может и сам написать.

Он в госструктуре какой-то работает, имей сочувствие.

Ну вот, хорошо. Правильно говорили, что реакции убивают конструктивный срач.

я тоже. zero tolerance.

Я писал кастомный мигратор на основе вот этого проекта, примерно по тем же причинам.

Можно также взять, затащить в свою кодовую базу и сказать что это часть проекта, что собственно и будет правдой.

я тоже

Ну ты должен же понимать, что там не всё так просто.

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

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

Хеш от пустой строки, внезапно, всегда равен хешу от пустой строки. В твоем варианте тебе все равно нужно вначале создать структуру прямо в базе. Не написать изменения структуры и присвоить номер этому делу, а фактически создать структуру в базе, выдернуть строковое представление структуры и посчитать от нее хеш, и только после этого сохранить хеш, пытаясь использовать его как номер миграции.

Мало того, тебе еще хеш не скажет, после какого хеша он стоит и перед каким, потому что в нем нет этой информации.