Witam
Jak co roku przed inwentaryzacją UKE przechodzę na aktualnego LMSa, jednak w tym roku chcę to zrobić produkcyjnie, więc nie chcę niczego pominąć przy migracji. Lecę tak: produkcyjny>LMS_011114>LMS_011115>LMS_011116>LMS_011117>LMS_011118>LMS_011119
przy aktualizacji z 14 do 15 mam masę błędów przy aktualizacji bazy danych (mysql), wszystkie z tego co widzę dotyczą tego, że LMS chce ustawić wartość deafult dla rekordu typu TEXT, co według mojej DB jest błędne
przykład mysql.2007053100.php CREATE TABLE templates ( id int(11) NOT NULL auto_increment, type tinyint NOT NULL, name varchar(50) NOT NULL, message text DEFAULT "" NOT NULL, PRIMARY KEY (id), UNIQUE KEY name (type, name) ) ENGINE=InnoDB;
Error Code: 1101. BLOB/TEXT column 'message' can't have a default value
Jeśli zmienię na "message text NOT NULL" jest ok, pytanie czy mogę coś zmienić w konfiguracji MySQL czy muszę ręcznie orać wszystkie zmiany
P.S. Skoro nie udaje się wykonać aktualizacji bazy, dlaczego skrypt zmienia nr wersji DB? To nie logiczne..
pozdr./seba
W dniu 12.03.2016 16:12, Sebastian Szczepański napisał(a):
Witam
Witam,
Jak co roku przed inwentaryzacją UKE przechodzę na aktualnego LMSa, jednak w tym roku chcę to zrobić produkcyjnie, więc nie chcę niczego pominąć przy migracji. Lecę tak: produkcyjny>LMS_011114>LMS_011115>LMS_011116>LMS_011117>LMS_011118>LMS_011119
przy aktualizacji z 14 do 15 mam masę błędów przy aktualizacji bazy danych (mysql), wszystkie z tego co widzę dotyczą tego, że LMS chce ustawić wartość deafult dla rekordu typu TEXT, co według mojej DB jest błędne
przykład mysql.2007053100.php CREATE TABLE templates ( id int(11) NOT NULL auto_increment, type tinyint NOT NULL, name varchar(50) NOT NULL, message text DEFAULT "" NOT NULL, PRIMARY KEY (id), UNIQUE KEY name (type, name) ) ENGINE=InnoDB;
Error Code: 1101. BLOB/TEXT column 'message' can't have a default value
Jeśli zmienię na "message text NOT NULL" jest ok, pytanie czy mogę coś zmienić w konfiguracji MySQL czy muszę ręcznie orać wszystkie zmiany
P.S. Skoro nie udaje się wykonać aktualizacji bazy, dlaczego skrypt zmienia nr wersji DB? To nie logiczne..
Potwierdzam - to nie logiczne, a konkretnie obsługa transakcyjności w MySQL/MariaDB. Zauważ, że wszystkie aktualizacje schematu bazy danych MySQL są poprzedzone poleceniem: BEGIN; a zakończone poleceniem: COMMIT;
Dlaczego MySQL mimo błędnego wykonania wcześniejszych zapytań sql w traksancji mimo tego wykonuje późniejsze zapytanie sql?
pozdr./seba
On 03/14/2016 01:39 PM, Tomasz Chiliński wrote:
Dlaczego MySQL mimo błędnego wykonania wcześniejszych zapytań sql w traksancji mimo tego wykonuje późniejsze zapytanie sql?
http://dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
W dniu 14.03.2016 13:56, A.L.E.C napisał(a):
On 03/14/2016 01:39 PM, Tomasz Chiliński wrote:
Dlaczego MySQL mimo błędnego wykonania wcześniejszych zapytań sql w traksancji mimo tego wykonuje późniejsze zapytanie sql?
Z czego wniosek, że MySQL od zawsze jak napotykał jakiekolwiek zapytanie modyfikujące schemat bazy danych to kończyło ono transakcję, więc dalej występujące zapytania operujące na danych działają już poza transakcją. Jak zatem zasymulować prawdziwą transakcyjność taką jak ma PostgreSQL w MySQL?
W dniu 14.03.2016 o 13:56, A.L.E.C pisze:
On 03/14/2016 01:39 PM, Tomasz Chiliński wrote:
Dlaczego MySQL mimo błędnego wykonania wcześniejszych zapytań sql w traksancji mimo tego wykonuje późniejsze zapytanie sql?
A co polecacie zrobić z wartością default dla pól typu TEXT? Bo ten problem zdaje się występuje powszechnie Mysql5 - http://stackoverflow.com/questions/3466872/why-cant-a-text-column-have-a-def...
Odznaczyć NULL czy może zmienić typ na VARCHAR(256), co będzie właściwsze i nie przysporzy problemów? Rozwiązanie podane w linku średnio mi się podoba, tym bardziej, że używam replikacji w mysql5
pozdr./seba
uczestnicy (3)
-
A.L.E.C -
Sebastian Szczepański -
Tomasz Chiliński