Przypadki testowe

[GringoXY]

W trakcie implementacji aplikacji jeśli napotkamy jakieś dziwne przypadki to w katalogu: https://github.com/PLProjektKompetencyjny/PK_6IO1z_Projekt4_DataBase/tree/develop/Test/TestQueries dorzucić skrypty, które powinny się wykonać poprawnie (zakończyć sukcesem) i takie, które powinny rzucić wyjątkiem. Dzięki temu Pan @StanislawHornaGitHub będzie wiedział co należy poprawić w walidacji po stronie bazy danych.

[GringoXY]

Przypadki jakie powinny zostać obsłużone.

1. Gdy użytkownik sie rejestruje trzeba sprawdzić czy w bazie nie już takiego adresu e-mail.
2. Gdy użytkownik aktualizuje adres e-mail należy sprawdzić czy w bazie danych przypadkiem już nie ma takiego adresu e-mail.

[StanislawHornaGitHub]

Przypadki jakie powinny zostać obsłużone.

1. Gdy użytkownik sie rejestruje trzeba sprawdzić czy w bazie nie już takiego adresu e-mail.
2. Gdy użytkownik aktualizuje adres e-mail należy sprawdzić czy w bazie danych przypadkiem już nie ma takiego adresu e-mail.

CREATE TABLE User_Account (
    ID serial primary key NOT NULL,
    E_mail varchar UNIQUE NULL, -- can be null (admins do not have to have one), unique - auth method for customers
    User_name varchar UNIQUE NULL, -- can be null (customers do not have one), unique - auth method for admins
    Password varchar NOT NULL,
    Is_active bool DEFAULT TRUE,
    Is_admin bool DEFAULT FALSE,
    Creation_date timestamp DEFAULT now(),
    Last_modified_at timestamp DEFAULT now(),
    Last_modified_by int NULL,

    CONSTRAINT E_mail_chk CHECK (check_validate_e_mail(E_mail)), -- check if email is matching regex pattern
    CONSTRAINT User_name_chk CHECK (User_name ~ '^[a-zA-Z]+$'), -- username contains letters only
    -- check if user or email is present
    CONSTRAINT E_mail_OR_User_name_chk CHECK (user_name IS NOT NULL OR E_mail IS NOT NULL) 
);

kolumna e_mail ma ograniczenie UNIQUE, więc jeśli będzie próba wprowadzenia dwóch rekordów o tej samej zawartości, to automatycznie zostanie rzucony wyjątek