devel: bump db version using date from filename (we dont need repeata…

[interduo]

…ble work to be done in upgradedb.php), also use transactions for all upgrade scripts

[chilek]

Myślałem o tym trochę jako o całościowym rozwiązaniu - nie wiem czy nie mamy gdzieś celowo w aktualizacjach schematu bazy danych zapytań SQL wyniesionych przez BeginTrans(), bo z jakiegoś powodu w ramach transakcji mogłyby powodować wywałkę (tak bywa, gdy najpierw pobierasz dane z tabeli, którą zaraz potem modyfikujesz w sensie schematu). Wypadałoby chyba wyposażyć uproszczony mechanizm aktualizacji w coś takiego jako rozwiązanie opcjonalne? Testowałeś aktualizację schematu już nową metodą od najwcześniejszej wersji schematu dostępnej w lib/upgradedb?

[interduo]

Testowałem to na pustej bazie.

Jeśli masz takie podejrzenia to wrzucę najstarszą archiwalną zanonimizowaną bazę jaką mam (gdzieś z około ~2010 roku) i puszczę update i dam znać.

[chilek]

Wrzuć schemat z 2004 roku i sprawdź - w tej wersji sprzed pierwszego dostępnej aktualizacji schematu. Proszę o test na pgsql i mysql.

[interduo]

Wytestowałem to tak:

sudo su - postgres -c 'dropdb lmstest';
git reset --hard 04446ea7a42f5a6d94448ae8968a41a8f75b2999;
git clean -f -d
sudo su - postgres -c 'createdb -E UTF8 -O lmsdbuser lmstest';
sudo su - postgres -c 'psql lmstest -f /var/www/html/lms/doc/lms.pgsql';
git checkout interduo/db_version_bump_improvements;
sed -i 's/DROP CONSTRAINT customerassignments_customergroupid_key/DROP CONSTRAINT IF EXISTS customerassignments_customergroupid_key/g' /var/www/html/lms/lib/upgradedb/postgres.2021050701.php
git clean -f -d
composer install
php devel/upgradedb.php

Zrobiłem test od 2005 roku dla psql i o dziwo tylko jeden błąd - naprawiłem go https://github.com/interduo/lms/pull/new/db-fix-upg2.

Jest sens testować tak starą ścieżkę?

1. Nawet każdy normalny Debianowiec wie, że aplikacje się podnosi seriami a nie od razu na najnowszego SID'a.
2. Nigdzie nie spotkałem instancji z przed 1.11.19.

MySQL testuje właśnie..

[chilek]

git checkout interduo/db_version_bump_improvements;

Dla pewności proponuję zrobić:

git checkout stable

i na bieżącej wersji stable robić test podniesienia schematu.

[interduo]

git checkout interduo/db_version_bump_improvements;

Dla pewności proponuję zrobić:

git checkout stable

i na bieżącej wersji stable robić test podniesienia schematu.

Postgresa testuje tak:

#czyścimy środowisko
git reset --hard origin/master && git clean -f -d;
sudo su - postgres -c 'dropdb lmstest';

#time machine
git rev-list -1 --before=2006-01-01 origin/master | xargs git checkout;
git clean -f -d;
sudo su - postgres -c 'createdb -E UTF8 -O lmsdbuser lmstest';
sudo su - postgres -c 'psql lmstest -f /var/www/html/lms/doc/lms.pgsql';

#time machine to stable
git reset --hard origin/stable

#brzydki hak na blad - oddzielny PR czeka na to
sed -i 's/DROP CONSTRAINT customerassignments_customergroupid_key/DROP CONSTRAINT IF EXISTS customerassignments_customergroupid_key/g' /var/www/html/lms/lib/upgradedb/postgres.2021050701.php
git commit -a -m commit_temp;
git clean -f -d;
composer update;

#zaciągam brzydko zminimalizowaną zmianę tylko dla stable
git cherry-pick 54f8b7eabe88aa787d72cdf1a40ad1735540a33e

php devel/upgradedb.php;

DB schema version bumped from 2005123000 to 2021072921 - test postgresql na zielono

[interduo]

MySQL testuje tak:

#czyścimy środowisko
git rev-list -1 --before=2006-01-01 origin/master | xargs git checkout --force
git clean -f -d
mysql -e 'DROP DATABASE IF EXISTS lmstest'
mysql -e 'CREATE DATABASE lmstest COLLATE = utf8_general_ci'
mysql -e 'GRANT USAGE ON lmstest.* TO lmsdbuser@localhost'
mysql -e 'GRANT ALL PRIVILEGES ON lmstest.* TO lmsdbuser@localhost'
mysql -e 'FLUSH PRIVILEGES'

#time machine
sed -i 's/TYPE=MyISAM/ENGINE=MyISAM/g' doc/lms.mysql
cat /var/www/html/lms/doc/lms.mysql | mysql lmstest


#time machine to stable
git reset --hard origin/stable
git clean -f -d;

#zaciągam zminimalizowaną zmianę tylko dla stable
git cherry-pick 54f8b7eabe88aa787d72cdf1a40ad1735540a33e

composer install;
php devel/upgradedb.php;

Tutaj jest kilka błędów SQL ale nie wynika to z PR - tylko z kodu zapytań albo z tego że używam mariadb.

sed -i 's/DROP accountid/DROP IF EXISTS accountid/g' lib/upgradedb/mysql.2008021500.php sed -i 's/ADD period/ADD COLUMN period/g' lib/upgradedb/mysql.2010122700.php

ALTER TABLE promotionassignments DROP KEY promotionschemaid
Cannot drop index 'promotionschemaid': needed in a foreign key constraint
ALTER TABLE promotionschemas DROP COLUMN ctariffid
Cannot drop index 'ctariffid': needed in a foreign key constraint

a potem już czysto.

Te problemy występują również bez tego PR.

Dodałem jeszcze pokazywanie wersji z której dokonujemy aktualizacje na output czasami przydatne.

[chilek]

ALTER TABLE promotionassignments DROP KEY promotionschemaid Cannot drop index 'promotionschemaid': needed in a foreign key constraint ALTER TABLE promotionschemas DROP COLUMN ctariffid Cannot drop index 'ctariffid': needed in a foreign key constraint

Może usunięcie tych zasobów SQL wymaga najpierw usunięcia kluczy obcych zdefiniowanych na tych właśnie polach?

[interduo]

Może usunięcie tych zasobów SQL wymaga najpierw usunięcia kluczy obcych zdefiniowanych na tych właśnie polach?

Dokładnie tak jest - ale naprawianie ścieżki MySQL nie jest przedmiotem tego PR. Ten błąd występuje na masterze podczas tej aktualizacji.

No i jeszcze jeden temat poboczny: Na origin/master zauważyłem inną rzecz na mariadb-server 1:10.5.15-0+deb11u1 jak masz błąd to drugie uruchomienie php devel/upgradedb.php powoduje kończenie upgrade bazy czyli możesz zostać bez jakiejś aktualizacji w środku. Wygląda jakby obsługa transakcji jakoś leżała (nie był robiony rollback w przypadku błędu). I nie pamiętam czy tak zawsze było dla MySQL bo go już nie używam dobre kilka lat.

Myślisz, że warto jest zagrzebywać się w to mimo że MySQL jest niewspierany?