Unlink schema version from component version (#1218)

Unlink schema version from component version (#1218)

Activities

wojciech.kapcia@tigase.net opened 4 years ago

Currently we version schema based on associated component version, which doesn't seem ideal - it requires adding empty files without any changes for example.

A better approach would be to version schema based on required changes in the database (more atomic changes) - it would simplify a lot of things:

we could do away with checking if something is present or not and just focus on applying changes to the database
we would be able to provide "undo upgrade" for particular changes
required schema version could be done based on presence of particular sql files (we do it currently for upgrade-schema to collect the files anyway)

wojciech.kapcia@tigase.net commented 4 years ago

Chat transcript:

[2020-10-21 12:42:22] <Me>: dzisiaj trafiłem na https://flywaydb.org/ - wygląda w sumie jak nasz "upgrader"
[2020-10-21 12:44:38] <Andrzej #>: ale do rzeczy, czym to się różni od tego co mamy?
[2020-10-21 12:45:24] <>: chyba "tylko" V,U,R?
[2020-10-21 12:58:27] <Me>: > chyba "tylko" V,U,R?
primo: nie sugeruję używania (podałem raczej jako ciekawostkę i potencjalną inspirację); główna róznica to właśnie wspomniane możliwości VUR i podejście do wersjonowania - używanie wersji schema a nie wersji komponentu i tutaj moglibyśmy sie zastanowić czy też nie użyć takiego podejścia (można by dodawać mniejsze zmiany w osobnych plikach schema i nie było by problemu ze "snapshot")
[2020-10-21 12:59:31] <Andrzej #>: do co wersjonowania schema, tak to by miało sens, może nawet 8.2.0_1.sql
[2020-10-21 12:59:37] <>: potem 8.2.0_2.sql
[2020-10-21 12:59:49] <>: ale zbiorczy by był 8.2.0.sql
[2020-10-21 13:00:20] <>: to by było wersjonowanie schema wewnątrz wersji - podoba mi się ta idea
[2020-10-21 13:00:31] <Me>: to jest w sumie do zrobienia obecnie. ale imho odklejenie od wersji komponentu mialby taki plus, ze nie trzeba by wstawiac pustych schema jakby nie bylo zmian
[2020-10-21 13:00:57] <Andrzej #>: tak, tylko kto i gdzie zapisze schema i będzie pamiętał o aktualizacji
[2020-10-21 13:01:43] <Me>: ha! dumalem nad tym i tutaj wyamgana wersje schema mozna by przy uruchamianiu wyliczac z plikow - brac najnowszy i sprawdzac czy jest w bazie (analogicznie jak obecnie sprawdzamy pliki do wczytania)
[2020-10-21 13:03:01] <Andrzej #>: to jest jakaś opcja
[2020-10-21 13:05:18] <>: > to jest jakaś opcja
i potencjalnie uprosiloby trochę rzeczy
[2020-10-21 13:05:29] <Andrzej #>: to co od 9.0.0 nowy sposób wersjonowania schema? (jestem mocno za)
[2020-10-21 13:07:12] <Me>: robimy 'baseline' i każda zmiana to osobny plik? + rozdzielenie tego na komponenty?
[2020-10-21 13:07:58] <Andrzej #>: o czymś takim myślałem
[2020-10-21 13:08:22] <Andrzej #>: czyli każde repo ma osobna "Schema"
[2020-10-21 13:08:27] <Me>: yup
[2020-10-21 13:08:40] <Me>: tzn to już postulowaliśmy i jest na to zadanie
[2020-10-21 13:08:48] <Andrzej #>: czyli server-offline-storage-8.2.0_1.sql ;)
[2020-10-21 13:09:11] <Me>: server-offline-storage-0.0.1.sql ? :-)
[2020-10-21 13:09:32] <Andrzej #>: moment, a co jest bazą?
[2020-10-21 13:09:39] <Me>: https://projects.tigase.net/issue/issue #1180
[2020-10-21 13:09:54] <>: bazą byłaby obecna wersja
[2020-10-21 13:10:05] <Andrzej #>: ale obecna to 8.2.0
[2020-10-21 13:10:06] <Me>: chociaż tez można by to rozdzielić na osobne pliki
[2020-10-21 13:10:12] <>: aa, rozumiem
[2020-10-21 13:10:13] <Andrzej #>: to jak to się ma do 9.0.0?
[2020-10-21 13:10:19] <Me>: w sensie jak to ugryżć z obecnymi wersjami
[2020-10-21 13:10:36] <Andrzej #>: no jakoś musimy
[2020-10-21 13:10:47] <>: dopuszczamy upgrade z version-2
[2020-10-21 13:10:48] <Me>: dobra, to jest do przemyślenia jeszcze
[2020-10-21 13:11:16] <>: tak, ale szlibyśmy nowym mechanizmem 
[2020-10-21 13:11:39] <>: eh... ale po części limit "upgrade z version-2" to bylo zeby nie trzymać masy zmian w schema i robić okresowe "flatten"
[2020-10-21 13:11:52] <>: chociaż... tutaj też co jakiś czas można by zwinąć starsze wersje schema w plikach
[2020-10-21 13:12:28] <Andrzej #>: ja myślałem o "hybrydzie"
[2020-10-21 13:12:56] <>: tzn. ostatnia wersja ma _1, _2
[2020-10-21 13:13:14] <>: ale fakt, lepiej by było by każda miała osobno zmiany i je tylko numerować od zera
[2020-10-21 13:13:30] <>: czyli "baseline" to 8.2.0 a potem narastająco
[2020-10-21 13:14:49] <Me>: tzn ja bym to widział tak, że przy aktualizacji byśmy rozpięli wersjonowanie komponentów od wersji schema, ale to byłby dosyć delikatny zabieg. przy czym IMHO przyszłościowo by nam później życie ułatwił
[2020-10-21 13:15:22] <Andrzej #>: co do tego to w pełni się gadzam
[2020-10-21 13:15:46] <>: nawet mając taki cuda (małe release) można by pokusić się o wygenerowanie "cofnięcia zmian"
[2020-10-21 13:15:53] <>: gdyby ktoś potrzebował
[2020-10-21 13:16:03] <Me>: no dokladnie
[2020-10-21 13:16:14] <>: wtedy dodanie "U___" byłoby prostsze
[2020-10-21 13:16:37] <Andrzej #>: chyba railsy tak działały? co "build" to plik ze zmianami
[2020-10-21 13:16:40] <Me>: i też poniekad odpadłby probelm z zapewnianiem wielokrotnego wczytywania i sprawdzaniem czy coś jest czy nie ma - zakładalibyśmy, że ktoś ma bazę w odpowiednim stanie
[2020-10-21 13:16:44] <>: yup
[2020-10-21 13:16:56] <>: tzn nie co build ale każda zmiana miała swoją wersję
[2020-10-21 13:16:58] <Andrzej #>: to by pomogło z DerbyDB (bardzo)
[2020-10-21 13:17:11] <>: (trochę skróciłem myślowo)
[2020-10-21 13:17:15] <Me>: i ten fly* zdaje się działa na podobnej zasadzie
[2020-10-21 13:17:50] <Andrzej #>: czy mi się wydaje czy mamy nowy projekt? tigase-schema-manager ;)
[2020-10-21 13:18:16] <Me>: no... w przyszlosci mielismy powydzielać troche rzeczy wiec... czemu nie? ;-)

wojciech.kapcia@tigase.net commented 4 years ago

I'm wondering if we shouldn't reorganise the schema files at the same time as well, possibly group them by database/component (i.e. mysql/muc/xxx.sql, mysql/offline/xxx.sql). One of the pain points previously was a mess we had in schema files so with multiple "atomic" schema changes this could became a problem again. What do you think @andrzej.wojcik ?

Andrzej Wójcik (Tigase) commented 4 years ago

We could do that, but copying from database to database/component/ should be done by distribution packaging.

wojciech.kapcia@tigase.net commented 4 years ago

Agreed but we would still should divide per database in component repositories (it would be simpler to configure distribution packaging).

Andrzej Wójcik (Tigase) commented 4 years ago

I know it would be simpler but somehow I do not like to be forced to create "component" directory in the database directory in the repository. At this point (as we are switching from component version based versioning to schema based versioning) maybe we should have database/repo instead of database/component and that would be more acceptable for me and it would keep each repo schema separated.

Andrzej Wójcik (Tigase) commented 4 years ago

I'm starting to wonder if we should not keep schema for each database separated

wojciech.kapcia@tigase.net commented 4 years ago

OK, I think we miscomunicated here. What I was proposing to:

group schema by database type
in case of repositories with multiple-component-schema (e.g. tigase-server) additionally add per-component grouping.

For example a) in tigase-server we would have src/main/database/mysql/offline/*.sql b) in tigase-pubsub we would have src/main/database/mysql/*.sql

Andrzej Wójcik (Tigase) commented 4 years ago

well, ok. I'm just not sure how would it look while merged for distribution but the idea looks ok.

wojciech.kapcia@tigase.net commented 4 years ago

In distribution it would be:

database/mysql/server/*.sql
database/mysql/offline/*.sql
database/mysql/muc/*.sql
database/mysql/pubsub/*.sql
database/postgres/server/*.sql
database/postgres/offline/*.sql
database/postgres/muc/*.sql
database/postgres/pubsub/*.sql
etc.

wojciech.kapcia@tigase.net batch edited 6 months ago

Name	Previous Value	Current Value
Iterations	empty	Candidate for next major release

Type	New Feature
Priority	Normal
Assignee	wojciech.kapcia@tigase.net
Version	Candidate for next major release

Iterations

Candidate for next major release Open

Related

#1180 Open

Extract schema for offline_messages, cluster and msg_broadcast

Issue Votes (0)

Watchers (2)

Reference

tigase/_server/server-core#1218

Please wait...

Page is in error, reload to recover