Git oraz Postgresql - mechanizm

Cześć,

nie wiem dlaczego jak pytam o działanie gita z postgresql ludzie odsyłają mnie często do narzędzi.

Czy ktoś podpowie jak to powinno działać?

1. Użytkownicy tworzą wersję nr 1, wyrzucają w czystym SQL (jako tekst) do repo na Gicie.
2. Uzytkownicy tworzą wesję 2, wrzucają do GIT'a i GIT automatycznie łapie deltę, czyli jakie mamy różnice.

Czego ja tutaj nie rozumiem?
Dlaczego tutaj się tak zastanwiają nad tym...

https://stackoverflow.com/questions/846659/how-can-i-put-a-database-under-git-version-control

Nie wiem czego nie rozumiesz, ale powiedz chociaż, co chcesz osiągnąć? Trzymać historię zmian schematu bazy? Czy o dane chodzi?

Ale chcesz DDLe trzymac czy co? Ja np. w Javce korzystam z Liquibase - XML opisuje zmiany takie jak dodawanie nowych kolumn etc.

@jaryszek: pokaże ci na przykładzie.
Załóżmy, że masz dwie tabele:
biblioteka(id PK, id_ksiązki, ...)
ksiazka(id PK, ...)
robisz sobie ich skrypty (załóżmy, że tabele są w tej kolejności w skrypcie - tak by pgdump zrobił) i nic się nie zmienia.
Pewnego dnia wpadasz o (słuszny) pomysł, że biblioteka(id_ksiazki) powinno być FK do ksiazka(id). Więc zakładasz go.
I teraz, nie dość, że zmieniła ci się struktura, to jeszcze wymuszona została inna kolejność tabel w skrypcie. Teraz ksiazki MUSZĄ być przed biblioteka.
Pomyśl sobie, jakie różnice będą w delta

@somekind: @scibi92 chodzi o ddl i dml, a więc o dwa z nich.

@Marcin.Miga dziękuję. To racja. No to rzeczywiście masakra by była.
Jednak, jakbym miał wersję 2 i chciał zrobić taki zabieg to musiałbym zdropować te tabele (wrócić do wersji 1) i jeszcze raz je założyć w dobrej koleności.
I w tym momencie mógłbym stracić dane...

Pozdrawiam,
Jacek

Delty tak naprawdę to powinno się pisać ręcznie.
Czy ktoś z Was stosuje na produkcji (tam gdzie są dane klientów) auto-generowane delty i to działa?
Jeśli tak to proszę o namiary na stosowane rozwiązanie.
Spotkałem się tylko raz z czymś takim - Sybase PowerDesigner potrafił to robić 15 lat temu, ale i tak nie miałem 100% zaufania.

@vpiotr a git złapie tekstową deltę przecież?

jaryszek napisał(a):

@vpiotr a git złapie tekstową deltę przecież?

Tak, ale ja o innej delcie pisałem.
Jak wygenerujesz skrypt struktury bazy danych w całości, to pomiędzy wersjami są różnice w strukturze.

Żeby je zastosować masz dwa rozwiązania:
a) skasować wszystkie dane plus bazę i stworzyć bazę od nowa pełnym skryptem.
b) uruchomić specjalnie spreparowane ALTER TABLE itp. DDLe.

Ja o tym drugim.

@vpiotr: rozumiem. To dotyczy głównie jak chcesz wrócić do poprzedniej wersji prawda? Dla automatyzacji można napisać jedynie samemu skrypt. Ja bym poszedł w jakieś API i jakby byl insert to pisałbym odwrotność automatem na podstawie PK. Chociaż nie wiem czy po założeniu triggera na DDLe mógłbyś tak napisac odwrotnego sqlka aby móc to łatwo odnowić

Jacek

Jak już zapewne zauważyłeś problem który starasz się rozwiązać jest bardzo trudny do rozwiązania w sposób automatyczny na relacyjnej bazie danych, skrypty migracyjne pomiędzy jednym i drugim schematem nawet jak są generowane automatycznie to i tak trzeba ręcznie poprawiać, już nie wspominając o śledzeniu zmian ddl i dml bez wsparcia ze strony bazy w stylu Temporal Tables w SQL Server jest ciężkie.

Ja bym się zastanowił nad alternatywnym rozwiązaniem problemu czyli jakaś baza dokumentowa + event sourcing jako bazowa architektura.
wersjonowanie dokumentów by rozwiązało problem z przełączaniem się pomiędzy schematami (ddl), ba jak dobrze by się napisało kod to jednocześnie mogłyby działać np wersje operujące na schemacie 3 i 5, na tych samych danych.
a event sourcing to po prostu zapisywanie każdej pojedynczej zmiany danych (dml).

@neves dziękuję. Właśnie tak chcę rozwiązać ten problem.
Tworzyć różne schematy , gdzie schemat = wersja.

2 torowe rozwiązanie:

1. Użytkownik tworzy wersję 2 (dodał tabele i rekordy), zakańcza, wrzuca do gita w czystym sql (ddl i dml oddzielnie) i widać różnice (deltę).
   1a. jak sie chce wrocic do poprzedniej wersji nalezy zrobic revert w GICie - wtedy sie straci dane niestety.
   1b. Chyba, że odwrócić tylko DDL a dane pozostawić, z tym że tutaj musiałby być skrypt, który pozwala nam revertowoć SQLki

2. Dodatkowo z wersji 2 tworzona jest kopia schematu i zawsze użytkownik może wrócić, sprawdzić co było zmieniane.

Chcę zrobić jedną tabelę z historią dla DDL i DML łapanych po trigerrach.I dzięki temu revert sqlków nie będzie taki zły.
Większość z nich, typu insert zrobię automatem z FE (Access) lub jakoś może da się to zaprogramować bezpośrednio w postgresql po PK.

Jacek

Nigdy nie spotkałem się z robieniem delty strukturalnej w bazie i aplikowaniu jej na produkcyjnym systemie (gdzie pojawia się również delta w danych...)

In-housowo mamy narzędzie, które:
a) wymaga utworzenia instancji repozytorium narzędzia (schemat bazodanowy)
b) wszystkie skrypty bazodanowe aplikowane są przez to narzędzie (w szczególności może zarządzać zmianami dla różnych systemów, różnych baz danych)
c) zmiany zorganizowane są w projekty: "instalacja od 0", "upgrade", "migracja między wersjami" , "mój wypasiony projekt"
d) W "upgrade" zmiany zorganizowane są na zasadzie paczek dla funkcjonalności bądź błędów (każdy plik z deskryptorem zmiany ma przyjętą konwencję nazewniczą: YYYYMMDD<seqno>_<ID buga/feature>.xml - więc przy tworzeniu releasu łatwo automatycznie wygenerować deskryptor projektu "wykonaj wszystko od 0 we właściwej kolejności" )
e) każdy deskryptor niesie metadane opisujące jak w ramach paczki skrypty mają być wykonywane (które zestawy skryptów sekwencyjne, które równolegle, jakie są zależności między zestawami skryptów, czy może być uruchomiony ponownie i masa innych funkcjonalności, które usprawniają zarządzanie releasami)

Development jest robiony przyrostowo (raz zreleasowane skrypty nie są modyfikowane!), np. może być taka historia:

1. Utworz tabele FOO (rok 2000)
2. Dodaj kolumne XYZ (rok 2003)
3. Dodaj kolulmnę ABC (rok 2008)
4. Ustaw dane w kolumnie ABC na podstawie danych z XYZ (razem z 3)
5. Usuń kolumnę DEF (2012)
6. Utworz trigger BAR (2018)

np. 2 klientów zaczyna używać systemu odpowiedni w 2004 i 2013 roku, to klient A przejdzie kilka "upgradów", a klientB będzie miał instalację od 0, na którą zostaną zaaplikoawne wszystkie upgrady.
W efekcie dla klientaB, krok 4 zostanie wykonany na "pustej kolekcji", zaś dla klientaA nie wiadomo co tam się uzbierało, ale wiadomo jak te dane zaktualizować.

Ciekawe rozwiązanie. Nie rozumiem połowy, ale sens rozumiem :)

1. Liquidbase
2. Flyway

Wybierz sobie jedno. Baza może być wtedy w kontenerze i masz w przysłowiowej pompie co się dzieje, bo po prostu budujesz bazę dla danego commita. Masz pełną historię zmian oraz automatyzację.

@yarel: ja mam bardzo dużo pytań :) Stąd też boję się, że Cię zamęcze.

Nigdy nie spotkałem się z robieniem delty strukturalnej w bazie i aplikowaniu jej na produkcyjnym systemie (gdzie pojawia się również delta w danych...)
Dlatego, że to ja wymyśliłem.
To być może będę wyrzucał całego dumpa - i wtedy miał zawsze deltę.

a) wymaga utworzenia instancji repozytorium narzędzia (schemat bazodanowy)

Jakbym zrobił to na schematach gdzie trzymałbym każdą wersję oddzielnie to byłby podobny efekt?

@Koziołek:

Liquidbase
Flyway

Flyway - brak możliwości rollbacku.
Te narzedzia rejestruja nam tylko DDLe, a co z DMLami?

Flyway - brak możliwości rollbacku.
Te narzedzia rejestruja nam tylko DDLe, a co z DMLami?

Flyway (inne też) nic nie rejestruje. Piszesz sobie sql na upgrade z wersji x do x+1, a czy to jest DDL, czy DML - Twoja rzecz.

@jaryszek: nie potrzebujesz rollbacku, bo budujesz z konkretnego commitu. Co do DMLi to są wspierane w liquidbase i we flyway.

Dziękuję.

DDL ok, ale DML? Za każdym dodanym rekordem musiałby stać skrypt SQL, jak to zautomatyzowac?

Jacek

Za każdym dodanym rekordem musiałby stać skrypt SQL, jak to zautomatyzowac?

A tu z pomocą przychodzą loadery. Definiujesz plik CSV dla danej tabeli a potem tylko konfigurujesz, przykład z liquidbase https://www.liquibase.org/documentation/changes/load_data.html

Zatem twoja rola ogranicza się tylko do dostarczenia danych.