Table of Contents

Namespace UsluzionicaServer.Domain.Entities

Classes

ApplicationUser
BookingRequest
Category
Conversation
DiscountTokenOffer
FavoriteListing
FavoriteProvider
Listing
ListingBoost
ListingImage
Message
Notification
PasswordResetCode

Jednokratni kod od 6 cifara za reset lozinke.

Zašto sopstvena tabela umesto Identity GeneratePasswordResetTokenAsync: taj token je dugačak i neprikladan za ručni prepis u aplikaciju, a Identity-jev TOTP provajder (koji daje 6 cifara) ima fiksan prozor od 3 minuta — prekratko ako se email zadrži u redu za slanje. Ovako imamo pun nadzor nad rokom trajanja, brojem pokušaja i jednokratnošću.

Kod se čuva HEŠIRAN (SHA-256). Ako baza procuri, kodovi nisu direktno upotrebljivi.

ProviderCategory
ProviderProfile
Referral
RefreshToken
Report

Prijava oglasa ili korisnika.

META JE DVA NULLABLE FK-a, NE POLIMORFNI int TargetId. Polimorfni ključ ne može biti strani ključ, pa baza ne bi imala nikakav način da proveri da meta uopšte postoji — a prijava koja pokazuje na obrisan red je gore nego nikakva, jer zauzima mesto u redu za admina i ne može se rešiti. Ovako CHECK ograničenje traži da je popunjeno tačno jedno polje, a FK čuva da ono na šta pokazuje zaista postoji.

Redovi se NE brišu kad se meta ukloni — to je revizijski trag. Zato su svi FK-ovi Restrict; oglasi se ionako arhiviraju, ne brišu fizički (ListingService.DeleteAsync postavlja Status = Archived).

Review
ServiceExecution
TokenPurchase
TokenTransaction
UserBlock

Jedan korisnik je blokirao drugog.

BLOKADA DELUJE SIMETRIČNO, iako je red usmeren. Ako A blokira B, nijedan ne vidi sadržaj onog drugog i ne mogu da komuniciraju. Red pamti KO je blokirao (da samo on može da odblokira), ali svaka provera vidljivosti gleda oba smera — vidi BlockService.

Asimetrična blokada bi bila polumera: B bi i dalje gledao A-ove oglase, pisao mu i prijavljivao ga. Onome ko blokira to ne rešava ništa.