Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

interduo
Copy link
Collaborator

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

lib/LMSDB_common.class.php Outdated Show resolved Hide resolved
@interduo interduo force-pushed the db_version_bump_improvements branch from 4d6a912 to 89bc4a9 Compare September 9, 2022 15:40
@interduo interduo marked this pull request as draft September 9, 2022 15:53
@interduo interduo force-pushed the db_version_bump_improvements branch 2 times, most recently from 6159c62 to 7533534 Compare September 9, 2022 17:10
…ble work to be done in upgradedb.php), also use transactions for all upgrade scripts
@interduo interduo force-pushed the db_version_bump_improvements branch from 7533534 to 110a563 Compare September 9, 2022 17:24
@interduo interduo marked this pull request as ready for review September 9, 2022 19:42
@interduo interduo marked this pull request as draft September 19, 2022 21:50
@interduo interduo marked this pull request as ready for review September 19, 2022 23:05
@chilek
Copy link
Owner

chilek commented Sep 20, 2022

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
Copy link
Collaborator Author

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
Copy link
Owner

chilek commented Sep 20, 2022

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

@interduo
Copy link
Collaborator Author

interduo commented Sep 20, 2022

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
Copy link
Owner

chilek commented Sep 20, 2022

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

interduo commented Sep 21, 2022

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

This comment was marked as outdated.

@interduo

This comment was marked as outdated.

@chilek chilek closed this in d4fa0e3 Jul 12, 2023
@interduo interduo reopened this Jul 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants