Uwagi do treści projektu

bd

(Kamil Listopad) #1

@pwi:

  • operacja new nie ma zaktualizowanego parametru emp tak jak w operacji root
  • operacja new wymaga sprawdzania czy admin jest dzieckiem emp1 albo jego przodkiem, do czego przydaje się zbudowany indeks w pamięci, który chcemy budować nie w fazie init. Czy to zamierzone? Może w fazie init możemy założyć, że ten warunek nie musi być sprawdzany, albo odłożyć jego sprawdzenie na koniec fazy init?

(Przemek) #2

specyfikacja:

[…] admin musi być pracownikiem emp1

Ja rozumiem, że “być pracownikiem emp1” oznacza “być pracownikiem o id emp1”. Gdyby, jak mówisz, znaczyło to “być podwładnym (dzieckiem) pracownika o id emp1”, to pracownik nie mógłby dodawać swoich padawanów; w szczególności szef (korzeń) nie mógłby nikogo zatrudnić.

Ja za to mam inne pytanie: jakiego typu jest identyfikator zadawany w root()?


(Przemek) #3

W specyfikacji nie ma doprecyzowane:

  1. Czy użytkownik init będzie istniał przed pierwszym uruchomieniem programu z argumentem -init?
  2. Czy baza danych, na której będziemy operować też już będzie istniała? Czy może jednak pierwsze-ever wywołanie open(database, …, …) z argumentem -init ma stworzyć bazę o nazwie database?

@mzr


(Jan Mazur) #4

Czy dostępny będze moduł pgcrypto ?


(Piotr Wieczorek) #5

Naniosłem kilka poprawek do treści specyfikacji. Dziękuję za uwagi.


(Wojciech Fica) #6

Czy mógłby Pan stworzyć jakieś, niekoniecznie duże, przykładowe testy?
Jest takie przykładowe wejście na stronie:

{ "open": { "baza": "student", "login": "init", "password": "qwerty"}}
{ "new": { "arg1": "value1", "arg2": "value2" } }

Czy funkcja new ma argumenty nazwane arg1, arg2?


(Przemek) #8

I czy argument open to baza jak w przykładzie czy database jak w dalszym opisie?

  1. Co należy zwracać jeżeli zapytamy sie o dane użytkownika, który nie istnieje?
    {"status": "OK", "data": "Null"} czy {"status": "ERROR"}?

(Wojciech Fica) #9

I czy passwd czy password? Teraz nie wiadomo bo są używane zamiennie.


(Przemek) #10

Małe testy:


(Jan Mazur) #11

Relacje descentant i ancestor nie są zwrotne, tak?


(Piotr Wieczorek) #12

Relacje descentant i ancestor nie są zwrotne.


(Radosław Miernik) #13

new <admin> <passwd> <data> <newpasswd> <emp1> <emp> dodawanie nowego pracownika o identyfikatorze <emp> z danymi <data> i hasłem dostępu <newpasswd>, pracownik <emp> staje się podwładnym pracownika <emp1>, <admin> musi być pracownikiem <emp1> lub jego bezpośrednim lub pośrednim przełożonym, <passwd> to hasło pracownika <admin>
// nie zwraca danych

Z opisu wychodzi, że <admin> musi być różny od <emp1> (bo nie jestem swoim pracownikiem ani przełożonym). W takim razie nigdy nie można wykonać new, bo nawet sam root nie może dodać kogoś sobie.

Stąd, przykładowy test jest niezgodny specyfikacją (choć zgodny ze zdrowym rozsądkiem):

{ "root": { "secret": "qwerty", "newpassword": "qwerty", "data": "dane prezesa", "emp":0} }
{ "new": { "admin": 0, "passwd": "123456", "data":"dane wiceprezesa", "newpasswd":"qwerty", "emp1":0, "emp":1 } }

Rozumiem, że jednak powinno być to możliwe i mogę sam sobie dodać podwładnego, tak?


(Kamil Listopad) #14

<admin> musi być pracownikiem o identyfikatorze <emp1>


(Maciej Buszka) #15

@pwi Czy program musi weryfikować poprawność wejścia (brakujące argumenty, niepoprawny json itp)?


(Piotr Wieczorek) #16

Wejście będzie zawsze poprawne od strony składniowej (json będzie poprawny, będą podane wszystkie argumenty i będą odpowiednich typów).
Może się zdarzyć, że operację będzie próbował wykonać ktoś nieuprawniony, ktoś poda nieprawidłowe hasło itp.