Cloud as a Story - Vunvulea Radu

Partea 1 http://vunvulearadu.blogspot.com/2011/02/propietati-de-tip-vector-in-tabele-din.html Continuare: In ultimul meu post am descris trei variante prin care se poate persista o entitate care contine o propietate de tip array( lista) intr-un tabel. Ultima varianta, care la prima vedere pare cea mai buna era folosind DataServiceContext . Aceasta solutie este viabila, atata timp cat nu trebe sa facem un query direct pe tabel. In acest moment tabelel din Windows Azure nu suporta pe query expresii de genu: Contains Count Select Din aceasta cauza, daca avem o propietate de tip lista nu o sa putem avea un query de genul: (item => item.ListaElemente.Contains(id) Din aceasta cauza, pentru a putea face un astfel de query ar fi nevoie sa incarcam toate elementele din tabel si sa le procesam din cod, cea ce nu tocmai optim. Dar nici prima varianta nu se poate folosii din pacate( lista sa fie stocata ca si un string cu un caracter despartitor), din cauza ca urmatorul query nu este suportat:...

Am inceput sa folosesc din plin tabelele din Windows Azure. Orice fel de date se pot salva acolo, atata timp cat sunt serializabile. Cu ajutorul lor am facut maparea unor entitati fara probleme. Am ajuns in momentul in care intre doua entitati A si B aveam o relatie n la m, iar intre alte doua entitati 1 la n. Fara nici o problema am scris: public List<Guid> ItemIds { get; set; } Am continuat sa scriu codul in continuare fara nici o problema, iar intr-un final am ajuns la unit-teste unde am avut o surpriza nu tocmai placuta. Cea ce am ignorat de la bun inceput a fost faptul ca tabele din Windows Azure nu sunt O/R, ele nu stiu sa stocheze in mod default o lista. Greseala mea, fapta fiind deja comisa a trebuit sa caut solutii la aceasta problema. Am gasit urmatoarele solutii: o propietate de tip string care sa stocheze id-urile despartite printr-un caracter special. Solutia destul de viabila, daca tinem cont de faptul ca obiectele care se stocheaza pe tabele nu ajung sa fie folosit...