Welcome Guest Search | Active Topics | Members | Log In

Identyfikatory wirtualne a przechowywanie referencji Options · View
habela
Posted: Friday, February 04, 2005 8:59:16 AM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Wydzieliłem ten temat z końca sąsiedniego wątku. Sprawa ważna. Stawką jest autentyczna przezroczystość perspektyw...

KK wrote:
No tak, ale dane do ktorych odnosi sie wirtualny indentyfikator moga nagle bez ostrzezenia przestac istniec... czy nie? W seedzie jest to co sie tam wsadzi, ale najczesciej sa to identyfikatory obiektow wyjsciowych (bo wtedy ma to jakis sens).
Jesli mamy np wirtualnego BogategoPracownika wskazujacego tak naprawde przez seed na obiekt Krzysztof, a ktos Krzysztofa zwolni, to na co bedzie pokazywal seed ?


KJS wrote:
No to nie widze tu roznicy miedzy obiektami skladowanymi i wirtualnymi. Przeciez jesli w tej sytuacji mam gdzies na pliku zapisaną referencje do obiektu Krzysztof i ktos go skasuje, to tez zostaje mi referencja donikąd. Tak naprawde dzieje sie wtedy to samo, co z BogatymPracownikiem.
stencel
Posted: Friday, February 04, 2005 10:32:23 AM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Tak wiec teza, ktora stawiam, jest taka:

W naszym podejsciu dane wirtualne sa pod tym wzgledem calkowicie przezroczyste, poniewaz w wypadku skladowania OIDa obiektu ktory usunieto, pozostaje nam zawsze wiszaca referencja niezaleznie do tego czy OID byl konkretny czy wirtualny.

Zapraszam do dyskusji.
subieta
Posted: Friday, February 04, 2005 11:02:52 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
stencel wrote:
Tak wiec teza, ktora stawiam, jest taka:

W naszym podejsciu dane wirtualne sa pod tym wzgledem calkowicie przezroczyste, poniewaz w wypadku skladowania OIDa obiektu ktory usunieto, pozostaje nam zawsze wiszaca referencja niezaleznie do tego czy OID byl konkretny czy wirtualny.

Zapraszam do dyskusji.


Idea aby zapamietywac referencje do obiektow rzeczywistych jest bardzo dobra i konieczna jako jeden ze srodkow organizowania zwiazkow asocjacyjnych (przez dane pointerowe). Idea, aby te referencje zapamietywac w przypadkowych miejsach, np. na pliku, jest bardzo niedobra, bo prowadzi do niespojnosci w postaci zwisajacych pointerow. Zapamiertywanie referencji jest uzasadnione tylko wtedy, jezeli pozostaja one zawsze pod kontrola tego mechanizmu, ktory dokonuje usuwania obiektow. Inaczej mowiac, mozna je zapametywac wylacznie w tym skladzie, ktory jest aktualnie otwarty do manipulacji. Powstaje oczywiscie pytanie dotyczace tego, ze czesc tego skladu jest na serwerze, czesc na kliencie, czesc zas sa to lokalne srodowiska procedur, na kliencie i na serwerze. Oznacza to jednak wylacznie odpowiednie protokoly w komunikacji klient-serwer, ktore uniemozliwia powstawanie zwisajacych referencji. Jak niektorzy pamietaja zapewne, w Loqisie bylo to zrobione przu pomocy backward pointers, co nie bylo zbyt wygodne, ale mozna to lepiej zorganizowac poprzez wprowadzenie specjalnych indeksow dla referencji (zadanie na prace magisterska).

Nie podejmuje sie na razie odpowiedzi na pytanie, czy zapamietywanie identyfikatorow wirtualnych ma sens. Idealistycznie, jezeli identyfikator jest wirtualny, to powinien byc zapamietany jako definicja, a nie jako materializacja. Problem polega na tym, z definicja ta w klauzuli virtual obiects definiuje od razu cala kolekcje takich identyfikatorow, a nie pojedynczy identyfikator. Byc moze mozna byloby te definicje tak zmodyfikowac, aby byla ona parametryzowana w taki sposob, ze wartosc tego parametru wyznaczalaby pojedynczy identyfikator wirtualny. Wtedy oczywiscie taka sparametryzowana definicja bylaby zapamietywana jako identyfikator wirtualny. Obawiam sie jednak, ze to prowadziloby do jakich powaznych schodow semantycznych i utrudnien dla programistow (braku pelnej przezroczystosci mechanizmu). Zapamietywanie identyfikatorow wirtualnych tak jak one sa obecnie reprezentowane jest moim zdaniem kompletnie bez sensu.

Moim zdaniem, nalezy do tego podejsc dokladnie w taki sam sposob, jak podchodzimy do aktualizacji wirtualnych obiektow. Przykladowo, ktos tworzy dana pointerowa przy pomocy instrukcji
Code:
create ref (MyView where MyAttr = "XYZ") as MyPointerObject;

Ludzkim jezykiem, ktos wywoluje view MyView, dokonuje selekcji, bierze z tego referencje i chce utworzyc dana pointerowa o nazwie MyPointerObject.
Nasz system orientuje sie, ze zapytanie przed as tworzy referencje w postaci identyfikatora wirtualnego, i w tym przypadku zamiast robic taki obiekt pointerowy, wskakuje do srodka definicji MyViewDef, gdzie znajduje odpowiednia procedure on_create_pointer, ktora robi to, co programista chce zrobic w tym przypadku.
stencel
Posted: Friday, February 04, 2005 12:43:20 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
subieta wrote:
Moim zdaniem, nalezy do tego podejsc dokladnie w taki sam sposob, jak podchodzimy do aktualizacji wirtualnych obiektow. Przykladowo, ktos tworzy dana pointerowa przy pomocy instrukcji
Code:
create ref (MyView where MyAttr = "XYZ") as MyPointerObject;

Ludzkim jezykiem, ktos wywoluje view MyView, dokonuje selekcji, bierze z tego referencje i chce utworzyc dana pointerowa o nazwie MyPointerObject.
Nasz system orientuje sie, ze zapytanie przed as tworzy referencje w postaci identyfikatora wirtualnego, i w tym przypadku zamiast robic taki obiekt pointerowy, wskakuje do srodka definicji MyViewDef, gdzie znajduje odpowiednia procedure on_create_pointer, ktora robi to, co programista chce zrobic w tym przypadku.


Idea jest zgodna z caloscia podejscia, ale jakos sobie nie wyobrazam jeszcze tego on_create_pointer. Moze jakies rozwiniecie tego przykladu od strony view? Czy to ma znaczyc, ze taka instrukcja ostatecznie da uzytkownikowi referencje do obiektu bazowego? Bo coz innego moglaby dac? Czy to jest bezpieczne?

Nie do konca rozumiem, dlaczego dla tego przykladu nie mozna w skladzie przechowac rzeczy takiej jak:

< i_new, MyPointerObject, <"I'am virtual", i_MyViewDef, i_XYZ> >

Przeciez ostatecznie taki wirtualny obiekt zawiera tylko referencje do obiektow bazowych.
Jesli wiec ktos usunie obiekt i_XYZ albo nawet i_MyViewDef, to mechanizm kaskadowego usuwania wiszacych referencji wytnie tez obiekt i_new?
subieta
Posted: Friday, February 04, 2005 1:56:51 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
stencel wrote:

Nie do konca rozumiem, dlaczego dla tego przykladu nie mozna w skladzie przechowac rzeczy takiej jak:

< i_new, MyPointerObject, <"I'am virtual", i_MyViewDef, i_XYZ> >

Przeciez ostatecznie taki wirtualny obiekt zawiera tylko referencje do obiektow bazowych.
Jesli wiec ktos usunie obiekt i_XYZ albo nawet i_MyViewDef, to mechanizm kaskadowego usuwania wiszacych referencji wytnie tez obiekt i_new?


W tym prostym przypadku mozna sobie to wyobrazic. Co bedzie jednak, gdy ziarno bedzie nie jedna referencja, lecz struktura dwoch referencji? Mozliwe sa rowniez bardziej skomplikowane przypadki, np. ziarno jest bagiem lub tablica. Na razie trudno mi sobie wyobrazic, czy we wszystkich takich przypadkach wystarczy wyciac obiekt i_new.

Na razie dyskusja jest akademicka, poniewaz najlepiej sprawe rozpatrzyc na przykladzie przypominajacym rzeczywista sytuacje biznesowa. Inaczej latwo sie zaplatac i dosc do scholastycznych dylematow, podobnych do dyskusji kowariancja/kontrawariancja, albo ile diablow moze sie zmiescic na koncu szpilki.
stencel
Posted: Saturday, February 05, 2005 11:26:30 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
subieta wrote:
W tym prostym przypadku mozna sobie to wyobrazic. Co bedzie jednak, gdy ziarno bedzie nie jedna referencja, lecz struktura dwoch referencji? Mozliwe sa rowniez bardziej skomplikowane przypadki, np. ziarno jest bagiem lub tablica. Na razie trudno mi sobie wyobrazic, czy we wszystkich takich przypadkach wystarczy wyciac obiekt i_new.


Zgadzam sie z tym. Trudno bedzie objac wszystkie przypadki. Natomiast idea z poprzedniego Twojego postu jest celna:

subieta wrote:
Nasz system orientuje sie, ze zapytanie przed as tworzy referencje w postaci identyfikatora wirtualnego, i w tym przypadku zamiast robic taki obiekt pointerowy, wskakuje do srodka definicji MyViewDef, gdzie znajduje odpowiednia procedure on_create_pointer, ktora robi to, co programista chce zrobic w tym przypadku.


Takiego czegos nam trzeba, gdy uzytkownik probuje wlozyc do skladu obiekt wirtualny. Moja najwieksza watpliwoscia bylo tu to, ze w wyniku takiego dzialania on_create_pointer uzytkownik moze dostac "goly" niezabezpieczony pointer do bazowego obiektu.

Ale to nie jest problemem! W naszej wymianie listow na temat zabezpieczania pointerow (overloading views) pisalismy o tym, co robic, gdy uzytkownik odwoluje sie przez pointer do obiektu bazowego, na ktorym sa overloading views. Obaj opisalismy podobny pomysl uruchomienia w takiej sytuacji overloading views:

subieta-to-stencel wrote:
Masz racje, problem mozna rozwiazac bardzo latwo. Moje rozwiazanie jest praktycznie identyczne z Twoim, z dokladnoscia do szczegolow. Pierwsze co musimy zdecydowac, to miejsce w skladzie, gdzie beda przechowywane overloading views. W przypadku salary takim miejscem byla klasa obiektow Emp. W przypadku gdy chcemy zrobic overloading obiektow korzeniowych (Emp i innych) najlepiej utworzyc specjalna klase dla calej bazy danych i tam trzymac wszystkie te overloading views. Jezeli tak zrobimy, to na stosie, w momemcie jego inicjacji pojawia sie dwie sekcje: po staremu sekcja bazy danych oraz wyzej sekcja z binderami do wszystkich zewnetrzych overloading views. Jezeli teraz przetwarzany jest pointer &426 i wykonywany jest na nim dowolny operator niealgebraiczy, to funkcja nested kladzie na stos pojedynczy binder Emp(&780), gdzie &780 jest referencja do obiektu Emp. W tym momencie, wiedzac o tym, ze obiekty Emp sa przeciazone, szukamy w specjalnej klasie czy przypadkiem nie ma tam overloading view przeciazajacego obiekty Emp. Jezeli sa, to jeszcze wyzej na stos kladziemy binder do najbardziej zewnetrznej takie perspektywy. Na tym sprawa sie konczy. Trzeba jeszcze zadbac tylko o to, aby nazwa Emp opatrzona slowem original wystepujaca w najbardziej wewnetrznej perspektywie szukala odpowiedniego Emp od gory stosu, a nie bezposrednio w sekcji bazy danych. W ten sposob dla przeciazajacych perspektyw cala populacja obiektow Emp zostanie zastapiona dokladnie jednym.


Tak wiec scenariusz jest dziecinnie prosty.

1. Uzytkownik wklada do skladu obiekt wirtualny.
2. Budzi sie procedura on_create_pointer i wklada do skladu jakis sensowny pointer niewirtualny.
3. Uzytkownik ma teraz "w reku" ten niewirtualny pointer i probuje sie przez niego dostac do obiektu.
4. W tym momencie wykrywany jest dostep przez "przykryty pointer" i w opisany powyzej sposob ten pointer niewirtualny jest zamieniamy na wirtualny. Robia to overloading views.

I wilk syty i owca cala!
habela
Posted: Sunday, February 06, 2005 10:03:06 AM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Sprawa wydaje mi się wykonalna, choć na razie jest sporo niejasności w tym pomyśle:
Quote:
1. Uzytkownik wklada do skladu obiekt wirtualny.

Czy to ma oznaczać, że wstawiamy obiekt (tj. np. jakieś konkretne dane, wstawione do własności, która wg schematu jest wirtualna. Wobec tego, zamiast je wprost zapisać, wymaga - zgodnie z przepisem zawartym w on_insert - ich przetłumaczenia na jakąś odmienną konkretną reprezentację w schemacie)?
Czy też chodzi o to, że wstawiamy jakąś uzyskaną wcześniej z jakiegoś zapytania i zapamiętaną referencję do obiektu wirtualnego?
Może przykład kodu, który to robi rozwieje wątpliwości...
Quote:
2. Budzi sie procedura on_create_pointer i wklada do skladu jakis sensowny pointer niewirtualny.

OK. Czyli raczej to drugie. Intencję on_create_pointer rozumiem dokładnie tak. W tej chwili nie jestem pewien, czy sensowny i niewirtualny nawzajem się nie wykluczają...
Problemem jest tu m.in. to, że jeśli ten pointer będzie w pełni niewirtualny i wskaże na jakieś ziarno, to przezroczystość jest utracona, bo dostajemy przez tę referencję dostęp do czegoś innego (inny interfejs, inny zestaw własności...) niż znany nam interfejs obiektu wirtualnego.
Quote:
3. Uzytkownik ma teraz "w reku" ten niewirtualny pointer i probuje sie przez niego dostac do obiektu.
4. W tym momencie wykrywany jest dostep przez "przykryty pointer" i w opisany powyzej sposob ten pointer niewirtualny jest zamieniamy na wirtualny. Robia to overloading views.

A więc jednak ten niewirtualny pointer jest specjalnie traktowany? W takim razie zakładam, że to, co jest w nim niewirtualnego, to zestaw (potencjalnie bardzo wielu - tyklo w najprostszych przypadkach jedna) źródłowych referencji koniecznych do skonstruowania obiektu wirtualnego. Trzeba się liczyć z tym, że któreś z tych źródłowych referencji też mogłyby być wirtualne...
Podsumowując - bez przykładu się nie obejdzie. A tak samo, jak update jednego obiektu wirtualnego może się przekładać na wiele konkretnych update-ów, tak i zapamiętanie referencji do jednego - może wymagać zapamiętania całej garści referencji źródłowych.
habela
Posted: Sunday, February 06, 2005 12:31:44 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Po wysłaniu poprzedniego posta nasunęło mi się takie spostrzeżenie.
1. Z jednej strony, zastanawiając się nad możliwością skutecznego odtwarzania obiektu wirtualnego, widać konieczność zapamiętania dlań takiej a nie innej kolekcji referencji źródłowych i definicja ziaren zasadniczo to determinuje. Np. dla obiektu zawierającego pary nazwisk kierownik - podwładny, trzeba dla istnienia takiego obiektu wirtualnego pilnować istnienia obu źródłowych obiektów pracownik i związku zatrudnia pomiędzy nimi. Jak coś z tych rzeczy wypadnie - trzeba sprzątnąć referencje do obiektu wirtualnego.
2. Z drugiej strony mogą istnieć inne sytuacje. Np. obiekt reprezentujący średnią płacę czy coś podobnego. Tutaj nie chcielibyśmy go tracić za sprawą każdej zmiany zestawu pracowników (ale może się tu gubię i w tym wypadku taki obiekt jest z definicji zmaterializowany??).

Czy zatem należy stwierdzić, że ewentualna operacja on_create_pointer dostarcza kryterium że tak powiem inwalidacji obiektu wirtualnego (tzn. wskazuje te składniki definicji ziaren, które dla istnienia danego obiektu wirtualnego muszą pozostać aktualne)?
stencel
Posted: Sunday, February 06, 2005 5:32:42 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
habela wrote:
Podsumowując - bez przykładu się nie obejdzie. A tak samo, jak update jednego obiektu wirtualnego może się przekładać na wiele konkretnych update-ów, tak i zapamiętanie referencji do jednego - może wymagać zapamiętania całej garści referencji źródłowych.


OK, Szefie i Piotrze, czuje sie przekonany, ze dyskusja na sucho nie ma sensu. Potrzebny jest nam przyklad. Sprobuje go wiec naszkicowac.

Bedzie to dotyczyc sklepu internetowego. W bazie danych znajduja sie obiekty o nazwie Towar, ktore reprezetuja towary do kupienia w sklepie. Klienci sklepu maja dostep do perspektywy TowarViewDef, ktora pozwala obejrzec wlaciwosci produktu (ma on_retrieve) oraz dodac o nim opinie do srodka obiektu skladowanego (perspektywa TowarViewDef ma wiec tez zdefiniowana operacje on_insert).

Klient ma dostep do towarow poprzez TowarViewDef. Klient moze zdecydowac sie na jakis towar i wtedy wklada obiekt pointerowy z referencja do wybranego towaru do obiektu Koszyk przechowywanego w lokalnym skladzie u klienta. Ów sklad lokalny moze byc nietrwaly lub trwaly.

Oczywiscie po pewnym czasie klient moze podejsc z tym Koszykiem do kasy i przerobic go na Zamowienie.

Pytanie: jak rozwiazac wkladanie wirtualnych referencji do Towaru do obiektu Koszyk?

Oczywiscie wiadomo, ze wszystko mozna zrealizowac przez metody viewsa, ale nam chodzi tu o najbardziej naturalne rozwiazanie dokladnie odzwierciedlajace faktyczne dzialanie klienta na poziomie pojeciowym/biznesowym, a więc:

Klient wkłada Towar do Koszyka.

Posiadana referencja do Towaru jest wirtualna.
KK
Posted: Monday, February 07, 2005 12:04:38 PM
Rank: Advanced Member

Joined: 12/7/2004
Posts: 226
Points: 30
stencel wrote:

Posiadana referencja do Towaru jest wirtualna.


Chyba najważniejsze jest, by przed wystawieniem Zamowienia dokonac kontroli poprawnosci wskaźnika, np w procedurze on_retrieve. Tyle że dla klienta to może być frustrujące. Normalnie mielibyśmy towar zablokowany w składzie na tego klienta... tylko jak długo mogą czekać rozpoczęte transakcje?
subieta
Posted: Monday, February 07, 2005 6:43:59 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
stencel wrote:

Takiego czegos nam trzeba, gdy uzytkownik probuje wlozyc do skladu obiekt wirtualny. Moja najwieksza watpliwoscia bylo tu to, ze w wyniku takiego dzialania on_create_pointer uzytkownik moze dostac "goly" niezabezpieczony pointer do bazowego obiektu.


Jest to sprawa programisty piszacego procedure on_create_pointer, jezeli on na to pozwala, to jego sprawa. Ma oczywiscie dowolnie duzo srodkow, aby to pozwolenie bylo ograniczone. W wielu przypadkach wirtualny pointer nie ma bezposredniego odpowiednika w postaci zapamietanego pointera (np. pointer od klienta do najczesciej kupowanych przez niego towarów), a wtedy procedura on_create_pointer zajmie sie zmiana struktur danych w taki sposob, aby powstalo wrazenie utworzenia odpowiedniego wirtualnego pointera.

Przy okazji, pomysl na procedure on_create_pointer jest szczegolnym przypadkiem pomyslu na tworzenie wirtualnych obiektow, ktory zostal juz opisany w doktoracie p.Hani, w postaci piatej procedury on_new dolozonej do istniejacych on_retrieve, on_insert, on_delete i on_update. Przyjmujac, ze praca doktorska p.Hani znajduje sie juz w public domain moge ja udostepnic na zyczenie zainteresowanych.

File Attachment(s):
PhD Thesis by Hanna Kozankiewicz.pdf (1,168kb) downloaded 46 time(s).


subieta
Posted: Monday, February 07, 2005 6:50:59 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
KK wrote:
stencel wrote:

Posiadana referencja do Towaru jest wirtualna.


Chyba najważniejsze jest, by przed wystawieniem Zamowienia dokonac kontroli poprawnosci wskaźnika, np w procedurze on_retrieve. Tyle że dla klienta to może być frustrujące. Normalnie mielibyśmy towar zablokowany w składzie na tego klienta... tylko jak długo mogą czekać rozpoczęte transakcje?


No, tu juz zostalo wrzucone do tego barszczu zbyt duzo grzybkow. Sprawe kontroli poprawnosci wlozymi miedzy asercje, ktorymi kiedys ktos sie zajmie, ale bedzie to odrebny duzy temat, w ktorym kontrola wirtualnych pointerow bedzie jednym z mikro-watkow. Transakcje sa w ogole przezroczyste dla tego mechanizmu, wiec ten aspekt traktuje jako nierelewantny do zasadniczego tematu.
KK
Posted: Tuesday, February 08, 2005 10:21:13 PM
Rank: Advanced Member

Joined: 12/7/2004
Posts: 226
Points: 30
Mam jeszcze takie pytanie.

Załóżmy że uda się wytworzyć jakiś system kontroli spójności wirtualnych referencji, wirtualnych identyfikatorów czy co tam jeszcze będzie nam potrzebne.
Czy taki system ma szansę działać w warunkach rozproszenia, przy założeniu autonomiczności poszczególnych węzłów biorących udział w zabawie?
KK
Posted: Tuesday, February 08, 2005 10:27:48 PM
Rank: Advanced Member

Joined: 12/7/2004
Posts: 226
Points: 30
subieta wrote:
KK wrote:

Chyba najważniejsze jest, by przed wystawieniem Zamowienia dokonac kontroli poprawnosci wskaźnika


No, tu juz zostalo wrzucone do tego barszczu zbyt duzo grzybkow. Sprawe kontroli poprawnosci wlozymi miedzy asercje,
[...]


Chodziło mi dokładnie o to, co napisał Krzysiek S. w punkcie 4.:

stencel wrote:

4. W tym momencie wykrywany jest dostep przez "przykryty pointer" i w opisany powyzej sposob ten pointer niewirtualny jest zamieniamy na wirtualny. Robia to overloading views.


Czy ten pointer wirtualny po zamianie zawsze bedzie pokazywal na sensowne dane?
subieta
Posted: Thursday, February 10, 2005 3:05:05 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
KK wrote:


Czy ten pointer wirtualny po zamianie zawsze bedzie pokazywal na sensowne dane?


Generalnie nie mozemy tego zapewnic w sposob automatyczny. Dotyczy to dowolnej procedury przeciazajacej. Wewnatrz takiej procedury programista moze napisac dowolny kod i nic nie stanie na przeszkodzie, jezeli ten kod bedzie bez sensu. Natomiast przyjmujemy zalozenie, ze bedzie sie on staral napisac ten kod tak, aby uzytkownik perspektywy mial odczucie pelnej przezroczystosci faktu, ze obiekt/pointer jest wirtualny. Pojecie przezroczystosci nie jest jednak zero-jedynkowe - rowniez w systemach bez aktualizowalnych perspektyw, ale z transakcjami, z mechanizmem bezpeiczenstwa, z wiezami integralnosci lub z trygerami uzytkownik nie ma pewnosci, ze to co zleci komputerowi bedzie dokladnie przez niego wykonane tak, jak sobie tego zazyczyl.
habela
Posted: Sunday, February 20, 2005 3:10:17 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Dotychczas zyskaliśmy intuicję, że dla określenia intencji autora perspektywy w zakresie zapamiętywania wskaźników potrzebna może być (podobnie jak dla określenia chociażby intencji aktualizacyjnych) jeszcze jedna specjalna procedura procedura.
Dla wznowienia dyskusji - może takie nieco kontrowersyjne pytanie:
Czy nie jest tak, że określenie niezbędnych danych źródłowych dla wyliczenia obiektu wirtualnego jest zdeterminowane przez rezultat zwracany w sekcji virtual objects?
Zmierzam do tego, czy bardziej intuicyjne nie byłoby uzupełnienie definicji perspektywy raczej procedurą on_resolve_pointer niż on_create_pointer...

W istocie jednak problem na razie z tą procedurą mam jeszcze poważniejszy. Szukam mianowicie przykładu, który pokaże, że sprawy nie można "zautomatyzować" i że taka procedura jest niezbędna.
Kilka scenariuszy:
a) Powracając do przykładu przytoczonego przez Krzyśka. Tam sprawa jest o tyle relatywnie prosta, że dla odtworzenia odpowiedniego obiektu wirtualnego Towar niezbędna jest referencja do jednego obiektu konkretnego. Czyli mamy relację 1:1 oraz konieczność zmaterializowania referencji obiektu konkretnego w zapamiętanej referencji obiektu wirtualnego, w momencie zapisywania tej drugiej.
b) Odmienna sytuacja to zapamiętanie wskaźnika do obiektu wirtualnego reprezentującego najczęściej kupowany w tym sklepie towar. Tutaj też jeden obiekt wirtualny opiera się na jednym obiekcie konkretnym. Ale tu intencją jest dotarcie nie do (konkretnego) towaru spełniającego ten warunek w momencie zapisania referencji, ale do towaru spełniającego ów warunek w momencie użycia takiej referencji.
c) Wariant powyższego - najczęściej kupowany towar dla danego klienta.
d) Obiekt wirtualny zawierający średnią wartość złożonych w sklepie zamówień. Załóżmy, że chcielibyśmy mieć możliwość aktualizacji przy każdym użyciu. Obiektów źródłowych jest wiele, ale zamiast pamiętać ich konkretny zestaw, chcemy móc zastosować na bieżąco formułę i wyliczyć na żądanie.

Przykłady obiektów wirtualnych same w sobie chyba dość naturalne, natomiast co do naturalności zapisywania do nich referencji - to może już nieco mniej.
e) Nie wymyśliłem teraz przykładu, w którym odtworzeniu obiektowi wirtualnego służyć musi zapamiętanie więcej niż jednego obiektu źródłowego (czyli takie złożone ziarna...?). Zapewne może coś takiego występować i może warto przytoczyć.

W każdym razie - w powyższych (myślę, że nie tendencyjnych przykładach), dla umożliwienia odtwarzania zapamiętanej referencji zauważyłem na razie (tylko) potrzebę:
- zapamiętania [jak widać wyżej, nawet nie zawsze, jeśli dotyczy] odpowiadającego danemu obiektowi wirtualnemu elementu rezultatu zwracanego przez sekcję virtual objects;
- określenia, czy operacje generyczne mają korzystać z elementu j.w., czy też dokonać wyliczenia (ale nie wykluczam, że to można zdeterminować za pomocą odpowiednio sformułowanej definicji virtual objects),

Dołączam się zatem do prośby o przykład, który pokaże, że odpowiedniej wirtualnej referencji nie sposób "wydedukować" z definicji perspektywy i że wobec tego jej budowa musi być sterowana dedykowaną do tego celu deklaracją.
radamus
Posted: Wednesday, February 23, 2005 12:53:59 PM

Rank: Advanced Member

Joined: 1/25/2005
Posts: 325
Points: 108
Location: Łódź
Nie wiem czy to co chcę napisać pasuje dokładnie do tego wątku ale spróbuję.
Zrobiłem przykład z wirtualnymi pointerami, który być może będzie jakąś cegiełką do zrozumienia problemu:

Załóżmy, że mamy zagadnienie integracji danych, gdzie w globalnym schemacie znajduje się perspektywa definiująca studenta. Same dane studenta znajdują się w różnych miejscach na zasadzie fragmentacji poziomej:



Definicja ziaren w perspektywie StudentDef wygląda następująco:

Quote:
create view StudentDef {

virtual_objects Student {
return (((Student1 as e) join (Student2 as f) join (Student3 asg)) where ((e.ID == f.ID) && (f.ID == g.ID))).
((deref(e.name) as name, deref(e.universityName) as universityName, deref(f.scholarship) as scholarship, deref(g.supervisior) as supervisior) as StudentGrid, e as Student1, f as Student2, g as Student3) as StudentSeed;
}

//pozostałe elementy definicji
}


Tworzymy strukturę nazwaną StudentGrid definiującą studenta (taki był przykład Hani pokazany mi przez Krzyśka na SOFSEM-ie. Dodatkowo dla przeciążenia operatorów aktualizacyjnych musimy posiadać referencję do obiektów, z których został utworzony nasz „gridowy student”, stąd dalsze budowanie struktury. Wynikiem jest struktura nazwana StudentSeed zawierająca cztery bindery.

Operator usuwania może teraz wyglądać następująco:
Quote:
on_delete { delete StudentSeed.Student1; delete StudentSeed.Student2; delete StudentSeed.Student3; }


Oczywiście można w ogóle nie robić na tym etapie dereferencji i zbudować seed obiektu Studenta po prostu z binderów do obiektów źródłowych. Ale nie to jest sednem tego o czym chcę napisać. Idziemy więc dalej.

Chcę zwrócić uwagę na to iż w globalnym schemacie zamiast atrybutu universityName mamy wirtualny pointer prowadzący do obiektu (być może wirtualnego) uczelni na której studiuje dany student. Czy obiekt do którego prowadzi wirtualny pointer jest wirtualny czy nie z punktu widzenia przezroczystości nie powinno definiującego perspektywę StudentDef interesować. Załóżmy więc, że widzi on obiekty University następująco:


Na poziomie globalnego schematu chcemy mieć możliwość wykonywania następujących przykładowych zapytań:
Podaj nazwisko rektora uczelni, na której studiuje student o imieniu Poe.

Quote:
(Student where name == ”Poe”).studyIn.University.chancellor;


Zgodnie z semantyką podejścia stosowego dotyczącego obiektów pointerowych operator niealgebraiczny działający na identyfikatorze takiego obiektu powinien wrzucić na czubek stosu binder do obiektu wskazywanego przez pointer. Nasz pointer jest wirtualny, więc to definiujący perspektywę musi tę informację wprowadzić. Moja propozycja dotycząca strony składniowej wygląda następująco (uwzględniając nasz przykład definicji ziaren).
Quote:
create view StudentDef {
//inne elementy definicji

create view studyInDef{
virtual_pointers studyIn {return ( StudentSeed.Student1 as source); }

point_to University{ return ref(University where name == StudentSeed.StudentGrid.universityName);}

on_update(newUniversity) { source.universityName = newUniversity.name; }
} }
//pozostałe elementy definicji
}


W rozprawie Hani jest propozycja, żeby procedura virtual_objects normalnie ustalająca ziarna obiektów wirtualnych ustalała wartość wirtualnego pointera (czyli to na co pointer pokazuje). (Tak naprawdę to nie do końca rozumiem skąd na stosie weźmie się nazwa obiektu Freelancer? Patrz rozprawa str. 94-95). Moja propozycja jest trochę inna. Niewątpliwie musimy ustalić na co wirtualny pointer wskazuje. Dlatego wyodrębniłem osobną procedurę o nazwie point_to. Nazwa procedury ustala nazwę obiektu wskazywanego tak samo jak nazwa procedury virtual_objects ustala nazwę wirtualnych obiektów. Natomiast sama procedura virtual_objects (nazwana u mnie virtual_pointers) ustala ziarna wirtualnego pointera. Przecież pointer też jest obiektem. A jak pokazuje nasz przykład takie ziarno może się przydać do aktualizacji. Zmieniłem również sam mechanizm przetwarzania. Wirtualny identyfikator wygląda następująco:
Quote:
<flag „I’m virtual pointer”, view_name, seed>

czyli jak u Hani. Seed jest wynikiem ewaluacji procedury virtual objects. Nie zmienia się ewaluacja procedur przeciążających. Na stos wrzucane jest nested(seed). Traktujemy wszystko tak jak byśmy mieli do czynienia z każdym inny obiektem. Różnica jest tylko w momencie gdy operator niealgebraiczny przetwarza wirtualny identyfikator. Następuje ewaluacja procedury point_to i jej wynik, nazwany zgodnie z nazwą procedury (w przykładzie University), wrzucany jest na czubek stosu ENVS. Oczywiście dla zgodności może zadziałać jeszcze na nim funkcja nested bo to zawsze będzie binder, więc niczego to nie zmieni.

To rozdzielenie umożliwia „aktualizację” wirtualnego pointera. Aktualizacja powinna wyglądać tak samo jak w przypadku zwykłego pointera czyli:

Quote:
(Student where name == ”Poe”).studyIn = ref(University where name = ”PJWSTK”);


Czyli podstawiamy na wirtualny pointer referencję do obiektu University. Semantyka tego podstawienia jest zdefiniowana w operacji on_update (patrz przykład definicji wirtualnego pointera).


Załóżmy teraz, że obiekty University są również wirtualne. Niech schemat będzie podobny jak u Studenta czyli fragmentacja pozioma:



Okazuje się, że dalej nasza aktualizacja działa. Pewnie wynika to z przykładu. Ale nie wymyśliłem innego.

Problemy jakie pojawiły się podczas analizowania przykładu:

1. Nie wiem jak napisać procedurę virtual_objects przy jednocześnie fragmentacji poziomej i pionowej, tak aby można było napisać procedurę przeciążającą operator usuwania takich wirtualnych obiektów. Dla jednej fragmentacji sprawa jest jasna (przykład podałem) ale przy mieszanej fragmentacji nie bardzo jestem w stanie to wyczuć.
2. Zakładając, że możemy napisać definicję operatora on_create_pointer. Nie wiem czy da się to zrobić dla tego przykładu. Załóżmy, że do wirtualnych obiektów University możemy wstawiać wirtualne referencje do studiujących na danej uczelni studentów. Na przykład:



Obiekt University musi być insertable. Przeciążona operacja on_insert definiuje semantykę tego wstawienia. Zapytanie wstawiające pointer do studenta (pamiętajmy, że student jest wirtualny) może wyglądać następująco:

Quote:
(University where name ==”PJWSTK”) < create ( ref(Student where name ==”Poe”) as attendee);


Mamy sytuację w której wyliczenie jakiejś rzeczywistej referencji jest niemożliwe bo mamy trzy obiekty (Student1, Student2, Student3) z których składany jest obiekt wirtualny.
Wpadł mi do głowy pomysł, żeby on_create_pointer tworzył referencję do procedury virtual_objects z perspektywy Studenta, ale musiała by ona być jakiś sposób parametryzowana konkretnym ziarnem. A nie wydaje mi się, że jest to możliwe.
A poza tym w naszym przykładzie akurat tworzenie pointera nie jest potrzebne bo semantyka wymaga po prostu zmiany nazwy uczelni w obiekcie Student1. Czyli jeżeli ustalilibyśmy na poziomie projektu co ma oznaczać tworzenie pointera do wirtualnego obiektu Studenta to być może dało by się to napisać.

To na razie tyle moich przemyśleń. Czekam z niecierpliwością na komentarze.
stencel
Posted: Wednesday, February 23, 2005 5:40:21 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
radamus wrote:
Code:
(Student where name == ”Poe”).studyIn.University.chancellor;


Zgodnie z semantyką podejścia stosowego dotyczącego obiektów pointerowych operator niealgebraiczny działający na identyfikatorze takiego obiektu powinien wrzucić na czubek stosu binder do obiektu wskazywanego przez pointer. Nasz pointer jest wirtualny, więc to definiujący perspektywę musi tę informację wprowadzić.


Do tej pory rozumialem, a z ostatnim zdaniem tu przestalem rozumiec. Operator algebraiczny zastosowany do obiektu wirtualnego powoduje wlozenie na stos srodowisk kilku sekcji, w tym zawartosc view (subviews) i binder do seedu obiektu wirtualnego. To wpada na stos. Nie widze gdzie tu jest miejsce dla jakis szczegolnych dzialan.

Prosze wiec o podanie stanu stosu i chwili obliczen, w ktorej nastepuje ten problem, ktory musi jakos rozwiaza definiujacy perspektywe.
radamus
Posted: Wednesday, February 23, 2005 7:16:09 PM

Rank: Advanced Member

Joined: 1/25/2005
Posts: 325
Points: 108
Location: Łódź
Już wyjaśniam.
Jeżeli operator niealgebraiczny przetwarza identyfikator wirtualny to na ENVS wrzucane są następujące elementy

Quote:


bindery do procedur virtual objects podperspektyw (czyli sack’ów) przetwarzanej perspektywy

nested(seed)

poprzedni stan stosu



tak jest w przypadku gdy mamy do czynienia z wirtualnym obiektem złożonym. Przy wirtualnym obiekcie prostym nie ma sekcji z binderami do sack’ów podperspektyw . Ziarno (seed) obiektu wirtualnego może być dowolne i jest nośnikiem informacji potrzebnej do aktualizacji wirtualnego obiektu. Czyli wykorzystywane jest przez procedury przeciążające generyczne operacje oraz przez podperspektywy. Czyli ziarno, moim zdaniem ma semantykę, nazwijmy ją, „wewnętrzną”. Siedzi w schowane w wirtualnym identyfikatorze i na moje czucie aktualizowalnych perspektyw jest częścią implementacji a nie interfejsu wirtualnego obiektu. Tylko definiujący perspektywę rozumie i wykorzystuje ziarno.
Czyli porównując rezultat funkcji nested identyfikatora rzeczywistego i wirtualnego obiektu:
Code:
nested(id_rzeczywisty_złożony) -> bindery do podobiektów
nested(id_rzeczywisty_prosty) -> pusty


Code:
nested(id_wirtualny_złożony) -> nested(seed), bindery do sack’ów podperspektyw
nested(id_wirtualny_prosty) -> nested(seed)


Czyli tak naprawdę różnią się o nested(seed). Bo bindery do sack’ów podperspektyw umożliwiają nam stworzene iluzji obiektu złożonego. W seedzie nie możemy tego umieścić.

Czyli dla wirtualnych pointerów powinno być podobnie:

Code:
nested(id_rzeczywisty_pointer) -> binder do obiektu wskazywanego przez pointer

nested(id_wirtualny_pointer) -> nested(seed), binder do obiektu wskazywanego przez pointer


Tylko, że pointer jest wirtualny (czyli go nie ma a co za tym idzie na nic nie wskazuje) i tak jak dla złożonego obiektu wirtualnego atrybuty musieliśmy zdefiniować, tak dla wirtualnego pointera musimy zdefiniować to na co on wirtualnie pokazuje. Ta definicja powinna również zawierać nazwę. Tak więc ENVS powinien wyglądać następująco:

Quote:


binder do rezultatu procedury point_to

nested(seed)

poprzedni stan stosu



Nie wiem czy udało mi się to dostatecznie jasno wyklarować.

I jeszcze jedno w propozycji Hani to ziarno ma definiować to na co wirtualny pointer wskazuje (tak to zrozumiałem). Moim zdaniem tak nie powinno być. Ziarno definiuje wirtualny obiekt (wirtualny pointer w tym wypadku) a nie to na co on wskazuje.
habela
Posted: Thursday, February 24, 2005 11:20:55 AM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Dobrze się złożyło, że dyskusja dotarła do tego miejsca, bo wreszcie pasuje do tytułu wątku który trochę niestarannie sformułowałem!
Na początku dyskusja obracała się wokół możliwości zapisania i późniejszej ewaluacji (jak najbardziej konkretnego) pointera do obiektu wirtualnego. Tutaj zaś mamy problem jak się wydaje poważniejszy.
radamus wrote:
W rozprawie Hani jest propozycja, żeby procedura virtual_objects normalnie ustalająca ziarna obiektów wirtualnych ustalała wartość wirtualnego pointera (czyli to na co pointer pokazuje). (Tak naprawdę to nie do końca rozumiem skąd na stosie weźmie się nazwa obiektu Freelancer? Patrz rozprawa str. 94-95).


Nie wypowiem się na tematy techniczne, bo brak mi tu implementacyjnego wyczucia.
Spróbuję się natomiast postawić w roli użytkownika takiej konstrukcji:
1. Nie zostałem na razie przekonany że (abstrahując od sposobu implementacji, który musi to oczywiście w specyficzny sposób obsłużyć) osoba definiująca perspektywę musi się posługiwać specyficznymi dla obiektów wskaźnikowych konstrukcjami, jak wspomniana procedura przeciążająca.
Jestem w stanie zaakceptować, że potrzebna jest np. jak u Hani klauzula as pointer.
Nawiasem mówiąc w tekście rozprawy jest chyba drobna niekonsekwencja w dyskutowanej składni. Wspomniane "as pointer" pojawia się najpierw (p.93) w ramach create view a później w ramach virtual objects (p.94). Ale to chyba drobiazg, bo te sekcje występują wszak 1:1.
Można by w dążeniu do uproszczeń pójść dalej i zapytać, czy w ogóle zamiast takiej klauzuli nie wystarczyłby operator ref w definicji ziaren. Ale może tutaj już przsadziłem...
2. Zainteresowało mnie sformułowanie w tekście rozprawy:
Hanka wrote:
The only problem with virtual pointers concerns their updates. Since virtual pointers have no identity, they cannot be updated. This is a slight violation of transparency requirement, which however cannot be avoided.

Czy ten problem jest faktycznie nie do przejścia?
Users browsing this topic
Guest


Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Main Forum RSS : RSS

Powered by Yet Another Forum.net version 1.9.1.6 (NET v2.0) - 11/14/2007
Copyright © 2003-2006 Yet Another Forum.net. All rights reserved.
This page was generated in 0.253 seconds.