Propietati de tip array in tabelele din Windows Azure (part 2)

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:

(item => item.ListaElementeSz.Contains(id.ToString())

Nu putem sa avem un query care sa foloseasca metoda Contains() pe string.

Singura varianta ramasa este a 2-a, folosirea unei tabele intermediare .

Read More

Propietati de tip array in tabelele din Windows Azure( part 1)

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 folosite pe partea logica si/sau client side;

• o tabela intermediara care sa stocheze relatiile intre cele doua obiecte. Pare o solutie bunicica, dar ma sperie putin ideea de a crea aceste tabele intermediare;

• ultima solutie gasita care m-a incantat cel mai mult este prin folosirea lui DataServiceContext. Acesta ne permite sa controlam momentul in care o entitate se salveaza sau se incarca dintr-un tabel si sa modificam continutul care se salveaza.

O sa detaliez mai jos aceasta varianta. Windows Azure salveaza toate aceste obiecte din tabele in format Atom Feed. Ce inseamna asta pentru noi? Pai, noi putem controla cea ce se salveaza si sa modificam continutul care ajunge sa fie salvat pe "tabele". Asa cum putem controla serializarea si deserializarea, cu ajutorul la DataServiceContext putem controla valoarea care se persista in tabele. Avem la dispozitie doua "metode":

• ReadingEntity: pentru citirea din tabel;
• WritingEntity: pentru scrierea in tabel;

Un exemplu de implementare puteti sa gasiti aici:
http://convective.wordpress.com/2009/12/30/entities-in-azure-tables/
In momentul acesta am de ales intre ultimele doua variante. Cred ca o sa aleg ultima varianta din cauza si altor neajunsuri pe care le are in momentul de fata Windows Azure la capitolul tabele( modul in care se genereaza un query).
Partea a 2-a: http://vunvulearadu.blogspot.com/2011/02/propietati-de-tip-array-in-tabelele-din.html

Read More