Rezerwacje obiektów — zadania

Zakres spotkań wykładowych

Karta obejmuje wykład 1 z 3 października oraz wspólny blok wykładów 2 i 3 z 24 października 2026 r. (4 × 45 min). Przypadki służą analizie żądań, uprawnień i zachowania systemu. Nie wymagają ukończonej implementacji laboratoryjnej.

Wasze zadanie

Budujecie własną aplikację fikcyjnego ośrodka „Sosna”. Nie korzystacie z baz ani kodu innych kursów. Wymagana jest podstawowa znajomość Pythona; środowisko i stan startowy udostępnia prowadzący.

  • P1: plac treningowy, dostępny; P2: sala symulatorów, niedostępna z powodu przeglądu.
  • Jednostki: A — Alfa, B — Bravo.
  • T oznacza jutrzejszą datę ustaloną na zajęciach. Wszystkie czasy mają jawną, wspólną strefę.
  • Rezerwacja kontrolna R1: P1, jednostka A, T 08:00–10:00.
  • Rezerwacja wymaga istniejącego, dostępnego obiektu i istniejącej jednostki. Początek poprzedza koniec i nie może być w przeszłości.
  • Przedziały są półotwarte: zawierają początek, nie zawierają końca. Dwie rezerwacje tego samego obiektu nie mogą nachodzić na siebie.

Na wykładzie przewidujecie wyniki żądań na podstawie tego przykładu; działanie serwera pokazuje prowadzący.

Jak pracujemy

Każda para przygotowuje schemat komunikacji, przykłady żądań i krótkie uzasadnienie. Każda osoba powinna umieć wyjaśnić wynik. Dane i zadania są niezależne od pozostałych przedmiotów.

Wykład 1 — Co się dzieje po kliknięciu „Rezerwuj”?

Materiał do zajęć

  1. Rozrysuj drogę od kliknięcia „Rezerwuj” do zapisu i odpowiedzi. Nazwij odpowiedzialność przeglądarki, API i bazy.
  2. Zaproponuj żądania odczytu i utworzenia rezerwacji. Co możesz stwierdzić, gdy odpowiedź po zapisie nie dotarła?

Materiały i zadania laboratoryjne zostaną udostępnione przed 8 listopada 2026 (4 × 45 min). Na wykładzie 3 października nie realizujecie laboratorium „Od zera do CRUD”.

Wykład 2 — Kto może zmienić rezerwację?

API i bezpieczeństwo — pierwsza część 24 października.

  1. Przy rezerwacji R1 08:00–10:00 porównaj próby 09:00–11:00 oraz 10:00–11:00 dla P1. Podaj warunek kolizji i oczekiwany kod odpowiedzi. Następnie wyjaśnij odmowę rezerwacji P2, mimo braku kolizji czasowej.
  2. W projektowanym wariancie z kontami użytkownik Alfy wskazuje rezerwację Bravo. Określ, jakie dane powinien sprawdzić serwer. Wyjaśnij, dlaczego ukryty przycisk i pole jednostka_id wysłane przez klienta nie wystarczają.

Pierwsze zadanie odnosi się do działającej walidacji demonstratora. Drugie opisuje rozszerzenie wymagające kont i kontroli uprawnień; aplikacja pierwszego etapu nie ma jeszcze tych mechanizmów.

Wykład 3 — Czy usługa zachowuje poprawny stan?

Współbieżność i wdrażanie — druga część 24 października.

  1. Dwa żądania rezerwują P1 na ten sam wolny termin. Zapisz przeplot operacji, w którym osobne sprawdzenie i zapis dopuszczają konflikt. Określ warunek poprawnego stanu końcowego oraz rolę transakcji rozpoczynanej przed odczytem.
  2. Po odtworzeniu kontenera lista rezerwacji jest pusta. Zaproponuj sprawdzenia ścieżki pliku i montowania danych. Następnie wyjaśnij, dlaczego dwie instancje z niezależnymi kopiami SQLite nie tworzą wspólnej ewidencji.

Uzasadnienie powinno odwoływać się do stanu danych i kolejności operacji, a nie tylko do nazw technologii. Szczegółowe zadania implementacyjne będą udostępniane wraz z laboratoriami 8 listopada i 13 grudnia.