the-sergiu / estore_platform Goto Github PK

Cerinta 2 nu exista (ca si task pentru studenti).
Ea exista ca si Testare (Verificare/Implementare)

-> Trebuie mutata undeva intr-un constructor (sau ca functie de apelat).

1. O solutie e sa apeleze set-eri de map-uri la fiecare Query (le dam noi sintaxa mura-n gura)

Daca dau git clone din git bash, voi avea problema cu LF/CRLF la file ending.
Daca dau git clone din WSL2, nu voi avea aceasta problema. De tinut minte sa recomandam aceasta solutie.

Cum procedam cu acele clase?

Ii lasam sa le creeze ei?
SAU
Le oferim o clasa goala in care isi pot scrie metodele?

CONCRET!!!!

1. Nu mai hardcodam datele de intrare si ne gandim + implementam citirea din fisier
   a datelor dorite
   a. Direct fisier newline (abordare C raw)
   b. JSON + biblioteca C++ (Misu) ***varianta preferata

-- CERINTA INITIALA
10. Diagrama UML Produse (Misu) (format re-editabil)

--CHECKER
11. Scriem verificari pentru implementarea tutoror claselor

Changelog:
08.08 12:30 A: Modificat unordered_map<int cosProduse*> si implementat functiile necesare pentru a adauga, modifica si sterge shoppingCart din cos. Modificat constructor default server pentru a testa si lista de useri. Initializare test map-uri. Adaugarea unui produs in cos a fost incheata cu succes :)).

08.08 S: Completat cap-coada clasa LRU Cache, unde accentul se pune pe metoda 'processRequests' ce reprezinta una din cerintele principale legate de LRU Cache. Primul pas este initializarea un obiect de tip LRUCache cu o capcitate data (in constructor). Metoda processRequests primeste un vector de int-uri (care abstractizeaza PID-uri de un anume tip), pe care il va procesa. Dupa ce se termina parcurgerea intregului vector, returneaza LRUCache in stadiul final procesarii.

13.08 A: Adaugat camp "producer" shoppingCart nealimentare si eliminat camp "Data Expirare" shoppingCart alimentare

14.08 A: Creat script Matlab pentru generare random de shoppingCart. Creat functie pe server ce primeste ca parametru calea unui fisier si populeaza lista cu shoppingCart a serverului. Creat functie de populeaza map-ul produsId-Product.

15.08 A: Eliminat camp "data nasterii" din user si camp "premiumSubscriptionCost" din user premium. Adaugat campuri "county" si "oras" in adresa.
Interfata nu are atribute, deci din start User si Product erau clase abstracte. Implementat constructori pentru User, ca sa pot initializa cele 2 obiecte agregate Address.

16.08 A: Creat script Matlab pentru Useri. Implementat citire useri din fisier si creare map UserCosProduse. Functionare testata. Implementat constructori pentru Product si modificat constructori Product alimentar si nealimentar pentru a utiliza constructorii din Product.

Parser JSON : https://github.com/nlohmann/json

Fisiere Intrare Jsoane, teste intermediareeeeee

Au aparut niste variante de rezolvare cvasi hard-codate ca rezolvare. Desi trec testul pentru LRU Cache, nu il trec pe cel pentru cerinta Bonus (ceea ce e bine - oarecum).

Sunt un inapt care nu e in stare sa scrie, pls help

-> nu mai ai cum sa parcurgi invers

-- Cerinta initiala (de proiect); 5p/100

Implementati ierarhia de clase pentru produsele din magazin, pronind de la diagrama diagrama UML. Ce constructori, operatori si alte metode sunt necesare? Nu uitati de get-eri si set-eri! ?? Atentie, nu vor exista obiecte de tip Product, ci doar subtipuri. ??

Acesta este un exercitiu pentru a va antrena in conceperea unei ierarhii de clase.

-- Tema propriu-zisa
( Sunt date fisierele .h, ce contin tipurile datelor si declararea functiilor necesare (pe care le vor implementa in .cpp) )

-- Implementati metodele descrise/necesare ierarhiei de shoppingCart. (Checker-ul verifica clasele)
Pentru implentarea corecta a claselor, de nota 5 (50/100 p)

• Pentru a testa clasele (de unele singure), commentati #include-ul claselor pe care nu intentionati sa le utilizati.

Initializati serverul. Listele de useri si shoppingCart sunt initializate folosind functii deja create, pentru a evita citirea din fisiere. Dupa acest pas, creati map-urile stocate pe server.

-- CERINTE
2. 2 tipuri de cautari/interogari/cerinte pentru manipularea datelor de pe server (folosind map-uri si listele de obiecte)

a. George are nevoie de un espressor nou. Fiind inainte de salariu, George cauta un produs redus. Astfel, cautati in lista de shoppingCart espressoarele reduse si returnati lista cu aceste shoppingCart (VALID - GetCategorie?)

b. Returnati o lista cu utilizatorii nonpremium care au un cost de transport < 11.5 lei. (VALID)

c. Gasiti toate produsele returnate si resigilate pe motivul "x". Sortati-le dupa price si salvati lista neomogena in fisierul de output.

d. Sortare shoppingCart alimentare dupa lastName, tara, price

e. Returnati o lista cu userii care au atat adresa de livrare, cat si cea de facturare la casa (adica nu la block) si locuiesc in judetul cu cei mai multi utilizatori. Sortati dupa UserID (VALID - problema sortare)

f. Returnati o lista cu toti utilizatorii premium care au cupoane de reducere pentru telefoane sau imprimante. (VALID - GetCategorie?)

3. LRU Cache + exemplu (implementare)

In general, cand vorbim despre resurse computationale si servicii oferite, mereu apare cuvantul "optimizare". Motivul e simplu: Daca operatiile se efectueaza suficient de repede, avem clienti multumiti. De asemenea, reducand spatiul ocupat pe servere, ajungem sa platim mai putin pentru serviciile Cloud. Astfel, atunci cand rulam milioane de operatii zilnic, optimizarea unei operatii ce are loc des (de exemplu accesul la o resursa populara), poate avea un impact masiv asupra serviciilor oferite.

Intuitiv, produsele populare vor fi destul de des accesate, deci ne-ar placea sa oferim acces "privilegiat" acestora. Acesta paradigma se traduce intr-o modificare hardware.
Asadar, pentru a implementa acest concept, vom simula un 'Least Recently Used Cache' pe server, care va retine id-ul produselor ce reprezinta ultimele accesari ale utilizatorilor.
Pentru o scurta explicatie asupra LRU Cache, click aici: https://www.youtube.com/watch?v=R5ON3iwx78M

Pentru a implementa cerinta, nu este nevoie sa stiti prea multe despre scopul si functionalitatile cache-ului intr-un sistem hardware, dar aici se afla o resursa utila in caz ca sunteti curiosi si vreti sa intelegeti mai bine puterea unui cache intr-un sistem de calcul: https://www.youtube.com/watch?time_continue=8&v=4McNhpkDNpQ&feature=emb_logo

Exemplu de functionare:
https://www.hackerrank.com/contests/justcode/challenges/lru-implementtion/problem

-> Corectarea duce la modificarea referintei primului test.

Probleme la output-ul fisierelor generate de test, in care unordered_map este nedetemrinistic.

Lista + Sortare in functie separata
vs
Vector si sortare oricum (bubble sort)

• Fiecare user va fi incarcat pe rand dintr-un fisier de tip JSON.

• Odata ce au fost incarcati toti utilizatori acestia vor putea realiza diferite actiuni
  *Ei vor putea sa vizualize continutul cosului de cumparaturi = GETCOS
  *Sa vizualizeze shoppingCart oarecare de pe site = GET(ID)
  *Sa adauge la cosul lor de cumparaturi = ADD(ID)
  *Sau sa stearga din cosul de cumparaturi = DEL(ID)
  *Sa comande ceea ce se afla in cousul de cumparaturi = BUY cee ce va face ca cantitatile de shoppingCart sa se modifice;

  Posibile : SEARCH?
  Deci toate actiunile posibile vor fi [GETCOS, GET, ADD, DEL, BUY]
  Acestea vor fi mediate de niste metode din clasa Server (cel mai probabil)

Modificarile facute de acestea se vor reflecta in state-ul in care se vor gasi
colectiile Cos de Cumparaturi si LRU.

Definitiile metodelor
List<Produse> GetCos(); Nu modifica nici LRU si nici Cosul

*List<Prouse*> Get(vector<int>); va primi o lista de ID-uri cu diferite tipuri de shoppingCart
	functia va updata LRU si va returna in schimb o lista neomogena cu toate produsele respective

*void Add(int); va lua ID-ul unui produs si il va adauga in cos. Va updata LRU de asemenea

*Void Del(int); va lua ID-ul unui produs si il va sterge din cos. Va updata LRU

Toate operatiile vor fi preluate din fisier

Exemplu de functionare

Avem PROD = [1, 2, 3, 5, 6, 7,8]
LRU = [,,]
USERS = { U1[,], U2[,], U3[,_]} **Fiecare user reprezentat cu propriu cos de cumparaturi

OP = operatii citite din fiser
REZ = Modificarile shoppingCart de operatie

OP: U1 -> Get(3,4)
REZ: LRU = [3,4,_] / Trimite[3, 4] (trimite o lista neomogena in care se afla produsele 3 si 4)

OP: U2 -> Get(4)
REZ: LRU = [4, 3,_] / Trimite[3]

OP : U2-> Add(1, 5)
REZ: U2[1, 5] / LRU[1, 5, 4] / Nu trimite Nimic

OP : U2 -> GetCos()
Rez: Trimite[1, 5]

OP : U2 -> Del(5)
REZ: U2[_, 5] Nu trimite Nimic

Userii pot avea reduceri la id-uri de produse la produse care nu exista.

Se va parcurge lista de produse si se vor salva toate id-urile categoriilor imprimanta si telefon, care apoi vor fi cautate in map-ul de reduceri al userilor premium. Implementational, functioneaza.

Problema este de logica.

(e.g. testare operator = in primele cerinte)

5. isi fac iei propria citire din fisierul json / dam structura json

[1, 2, 3, 4, 5, 6, 9]
capacitate = 3
vector<vector>
{
[1, -1, -1]
[2, 1, -1]
[3, 2, 1]
[4, 3, 2]
.
.
.
// state final fara toti pasii
}
5)
,
FISIER INTRARE CERINTA 5
[
{usserID = '1', produsID='2', actiune='Modifica=2'}
{usserID = '1', produsID='2', actiune='Modifica=2'}
{usserID = '1', produsID='2', actiune='Modifica=2'}
{usserID = '1', produsID='2', actiune='Modifica=2'}
{usserID = '1', produsID='2', actiune='Modifica=2'}
{usserID = '1', produsID='2', actiune='Modifica=2'}
]
OUTPUT CERINTA 5
///OBS {userID : cosProdus} este map-ul de pe server
[
Users = [
{uderID="" cosProds=[ , , , ]
{uderID="" cosProds=[ , , , ]
{uderID="" cosProds=[ , , , ]
{uderID="" cosProds=[ , , , ]
]

LRU = [1, 2, 3, 4, 5, 6...]
]

Struct puta{
a
b,c
}
s
vector vec;

Noi facem doar citirea -> si ei fac adaugarea la cos produse

Espressor nu este o categorie. Este un tip de produs. CUM REZOLVAM PROBLEMA DE LOGICA?

Am facut eu Setteri si Getteri. Asteptam feedback de la Udrea, dupa care unul din voi va face restul modificarilor.