Citat:
Znaci, hoces da kazes da je u relnoj aplikaciji prihvatljivo da ako se objekat sastoji iz "ime, prezime, jmbg" i promeni se samo "jmbg" da se izvrsi update tipa
...
I sve se vrednosti opet upisu (iako su iste)?
Sa stanovista performansi potpuno je isto da li menjas polje ili red. Ali sa stanovista logicne konzistentnosti podataka nije isto niti pod razno, zato sto se uvek backpostuju sva polja nazad u bazu (cak i nezimenjena) sto moze da pregazi promene koje je u medjuvremenu napravio eventualni drugi korisik. Pogledaj sledeci scenario
1. Korisnik A procita Osobu (Ime, Prezime, Adresa)
2. Korisnik B procita Osobu (Ime, Prezime, Adresa)
3. Korisnik B promeni samo Adresu i zapise nazad celu Osobu
4. Korisnik A promeni samo Ime i Prezime, i napise nazad celu Osobu.
U ovom slucaju ce Korisnik A u koraku 4. pregaziti promenu Adrese, zato sto se uvek zapisuje cela osoba a ne samo promenjena polja, a korisnik A ima zastarelu vrednost polja Adresa. Zato npr. Delphi ADO wrapper to resava tako sto radi
UPDATE Osoba SET Ime=@Ime, Prezime=@Prezime, Adresa=@Adresa WHERE Ime=@OldIme AND Prezime=@OldPrezime AND Adresa=@OldAdresa
Ako aplikacija ima zastarele vrednosti update failuje, tj. ne izmeni ni jedan red, sto je catchable u programu. Koliko je ovo resenje dobro je diskutabilno, pogotovo sa stanovista performansi, mada uspesno resava fantomske izmene polja nastale usled prevelike univerzalnosti DataLayer koda.
@mmix
Citat:
Primetices da ni dataset adapteri, ni linq, ni ef ne vode dirty flagove na nivou polja vec na nivou redova.
Zar datacontext u EF-u nema ObjectStateManager koji vodi promene na nivou polja entitete? Znam da sam bas to koristio za izvlacenje Diff-a izmedju starog i novog zapisa. E sad, nisam siguran da li to poštuje pri generisanju update SQL-a.
if it walks like a duck and quacks like a duck, it could be a dragon doing a duck
impersonation.