Welcome Guest Search | Active Topics | Members | Log In

JOBC, NOBC i praca z identyfikatorami i referencjami Options · View
mdabrowski
Posted: Friday, July 03, 2009 10:23:37 AM
Rank: Member

Joined: 6/18/2009
Posts: 24
Points: -25
Location: Warszawa
nina wrote:
Moj przyklad to tylko pseudokod. Wiadomo ze nie zadziala jak sie go przeklei. Wazna jest idea.


Pseudo nie pseudo, ja tylko pokazałem, że interpreter SBQL-a już dziś się przed tym broni i to bardzo prosto i skutecznie.
subieta
Posted: Friday, July 03, 2009 10:23:49 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
nina wrote:
stencel wrote:
Zaraz, zaraz. Nina, z Twojej wypowiedzi wynika, ze z referencjami obiektow wyslanymi do klienta nie mozna nic zrobic. Z drugiej strony SBA/SBQL przewiduje referencje do obiektow jako jeden z podstawowych elementow zbioru mozliwych wynikow zapytan. To jaki to ma sens?


Taki ze artykul na konferencje to jedno, a rzeczywistosc to drugie. Jest 100 milionow podobnych problemow do rozwiazania zanim z SBQL zrobi sie produkt.

mariusz wrote:
Jak w takiej sytuacji identyfikować obiekty wybrane przez użytkownika z poziomu np. Javy?


Tak samo jak to sie robi w RBD.

Nie jestem pewien, czy nie następuje tu zbytnia demonizacja problemu. Jezeli referencja w ODRA ma postać fizycznego adresu, to rzeczywiście bedzie mozliwe penetrowanie całej bazy danych przez losowo generowane referencje. Ale to mozna ukrócić np. poprzez zobowiazanie klienta np. do podania typu obiektu identyfikowanego przez referencję. To praktycznie wykluczy strzał w magmę bajtów, jeżeli typ obiektu jest jakoś w nim widoczny (powinien być). Można także sprawdzać, czy referencja wysłana przez klienta jest referencją do poczatku obiektu (co jest nieco trudniejsze, ale możliwe przy odpowiedniej organizacji składu)
nina
Posted: Friday, July 03, 2009 10:27:17 AM
Rank: Advanced Member

Joined: 1/7/2007
Posts: 11
Points: 33
Location: Bkk
subieta wrote:
Nie jestem pewien, czy nie następuje tu zbytnia demonizacja problemu. Jezeli referencja w ODRA ma postać fizycznego adresu, to rzeczywiście bedzie mozliwe penetrowanie całej bazy danych przez losowo generowane referencje. Ale to mozna ukrócić np. poprzez zobowiazanie klienta np. do podania typu obiektu identyfikowanego przez referencję. To praktycznie wykluczy strzał w magmę bajtów, jeżeli typ obiektu jest jakoś w nim widoczny (powinien być). Można także sprawdzać, czy referencja wysłana przez klienta jest referencją do poczatku obiektu (co jest nieco trudniejsze, ale możliwe przy odpowiedniej organizacji składu)


Moj przyklad "hacku" poradzi sobie z oboma takimi ograniczeniami.
mdabrowski
Posted: Friday, July 03, 2009 10:40:27 AM
Rank: Member

Joined: 6/18/2009
Posts: 24
Points: -25
Location: Warszawa
To może zamieniać referencje przed wysłaniem do klienta na nietrwały numer i zapamiętać po stronie serwera to mapowanie. (już dziś mamy taką konwersję, bo SBQL zwraca Reference a do klienta trafia RemoteReference, trzebaby tylko ją jeszcze bardziej uabstrakcyjnić, można chociażby użyć SHA1 lub jakiegoś własnego mechanizmu generowania liczb) i przy przeprowadzaniu rekonstrukcji z numeru na referencję sprawdzać, czy dany klient otrzymał do dyspozycji wcześniej w wyniku swoich zapytań taką referencję.
Nie będzie żadnego strzelania w magmę obiektów.
nina
Posted: Friday, July 03, 2009 11:10:24 AM
Rank: Advanced Member

Joined: 1/7/2007
Posts: 11
Points: 33
Location: Bkk
Nie da sie raczej. Taki bufor musialby miec ograniczony rozmiar, a wiec w ktoryms momencie jakas regula mapowania musialaby z niego wyleciec zeby zrobic miejsce na nastepna. Wtedy referencja bedaca od dluzszego czasu po stronie klienta, bazujaca na mapowaniu ktore wylecialo z bufora, nie moglaby byc odtworzona.

Byc moze problem daloby sie rozwiazac poprzez trzymanie tabeli translacji dla calej bazy danych (wszystkich obiektow), z ktorej korzystaloby sie tylko przy wejsciu/wyjsciu do bazy danych (przy dodatkowym koszcie dla operacji create/delete). To jednak oznacza inna architekture, a ja pisze o architekturze obecnej.
Mariusz
Posted: Friday, July 03, 2009 12:08:47 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 235
Points: 210
Location: Warsaw
nina wrote:

mariusz wrote:
Jak w takiej sytuacji identyfikować obiekty wybrane przez użytkownika z poziomu np. Javy?


Tak samo jak to sie robi w RBD.

To się nie sprawdzi. W relacyjnej bazie danych mamy klucze, które można systemowo odczytać, tzn. istnieje API podające klucze dla dowolnej tabeli. Odpowiednikami takich kluczy byłyby właśnie referencje.
mdabrowski
Posted: Friday, July 03, 2009 1:26:41 PM
Rank: Member

Joined: 6/18/2009
Posts: 24
Points: -25
Location: Warszawa
nina wrote:
Nie da sie raczej. Taki bufor musialby miec ograniczony rozmiar, a wiec w ktoryms momencie jakas regula mapowania musialaby z niego wyleciec zeby zrobic miejsce na nastepna. Wtedy referencja bedaca od dluzszego czasu po stronie klienta, bazujaca na mapowaniu ktore wylecialo z bufora, nie moglaby byc odtworzona.


Chcesz powiedzieć, że tworzymy zaawansowaną bazę danych z indeksami, optymalizatorami i Bóg wie czym a nie zmieści się w niej mapa typu <int, RemoteReference> ? Przecież jak tworzymy indeks na klasie to nie martwimy się o to, że ma n elementów, bo n+1-szego nie będziemy w stanie już zaindeksować. Przecież Java to nie C gdzie trzeba alokować zawczasu pamięć pod tablice.

Z tego co rozumiem kod, to takie indeksy są po prostu obiektami naszej bazy. Tutaj mogłoby być podobnie. Choć to chyba nie jest konieczne.

A tworzenie takiej struktury "na boku" dla całej bazy wydaje się za dużym nakładem. Prościej tworzyć to mapowanie "as needed" w ramach przesyłania referencji do klienta. Co więcej, można by ograniczyć widoczność tych mapowań do socketu by jeden klient nie "jeździł" po referencjach drugiego.
nina
Posted: Friday, July 03, 2009 2:35:19 PM
Rank: Advanced Member

Joined: 1/7/2007
Posts: 11
Points: 33
Location: Bkk
mdabrowski wrote:
Przecież jak tworzymy indeks na klasie to nie martwimy się o to, że ma n elementów, bo n+1-szego nie będziemy w stanie już zaindeksować. Przecież Java to nie C gdzie trzeba alokować zawczasu pamięć pod tablice.


Java nie tylko sama alokuje pamiec, ale rowniez sama ja zwalnia.

Wlasnie na tym polega naiwnosc wspolczesnych programistow. Wiara, ze jak sie cos przykryje jakims mechanizmem (alokacja pamieci garbage collectorem), albo frameworkiem (sql hibernatem), to problemy z tym co siedzi pod spodem znikna na zawsze.
subieta
Posted: Friday, July 03, 2009 3:08:43 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
nina wrote:
Java nie tylko sama alokuje pamiec, ale rowniez sama ja zwalnia.

Wlasnie na tym polega naiwnosc wspolczesnych programistow. Wiara, ze jak sie cos przykryje jakims mechanizmem (alokacja pamieci garbage collectorem), albo frameworkiem (sql hibernatem), to problemy z tym co siedzi pod spodem znikna na zawsze.

Nie zrozumialem argumentu. Jest dobrze czy źle? To że jakiś mechanizm przykrywa coś, to jest chyba dobrze, programista nie musi o tym myśleć. Jezeli jednak mimo przykrycia musi myśleć, to oznacza że przykrycie jest do d...

Wracając do zasadniczego wątku, podsumowanie dyskusji jest takie: jedna grupa zwolenników chce referencji po stronie klienta JOBC/NOBC i chce walczyć z zagrożeniami, druga grupa natomiast rozdziera szaty i straszy ogniem piekielnym, sugerując przy tym brak wyobraźni przedstawicieli pierwszej grupy.

Osobiście nie wierzę w ognie piekielne, więc nie ma co rozdzierać szat. Możemy zrobić jak sobie chcemy, i nie wykluczone, że się trochę przy tym poparzymy. Ale bedzie nowe doświadczenie, wolne od jałowego czarnowidztwa.

Dla czarno widzących przypominam, ze nie ma rzeczy absolutnie niezawodnych. Dlzczego zwracanie referencji na strone klienta miałoby być absolutnie wolne od wad? Bedą wady, trzeba będzie z nimi walczyć.
nina
Posted: Friday, July 03, 2009 3:21:44 PM
Rank: Advanced Member

Joined: 1/7/2007
Posts: 11
Points: 33
Location: Bkk
subieta wrote:
Nie zrozumialem argumentu. Jest dobrze czy źle? To że jakiś mechanizm przykrywa coś, to jest chyba dobrze, programista nie musi o tym myśleć. Jezeli jednak mimo przykrycia musi myśleć, to oznacza że przykrycie jest do d...


Przyklad z hibernate: wszystkie wiersze w bazie danych sa obiektami Javy, np. wszystkie wiersze emp sa po stronie Javy lista obiektow klasy Employee. Dopoki przetwarzamy takie obiekty punktowo to wszystko jest ok, ale jesli chcemy w ten sposob zaktualizowac pensje wszystkim pracownikom to dostaniemy n-selectow i n-updatow, gdzie n to liczba pracownikow. Wniosek: przykrycie jest do d..., ale programistom wydaje sie ze jest super i nie musza sie martwic zadnym sqlem ani optymalizacjami.

p.s. Nie bede juz drzec zadnych szat. Zamykam sie na wieki. Wystarczajaco mocno sie juz poparzylam.
Mariusz
Posted: Friday, July 03, 2009 4:59:28 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 235
Points: 210
Location: Warsaw
nina wrote:

Przyklad z hibernate: wszystkie wiersze w bazie danych sa obiektami Javy, np. wszystkie wiersze emp sa po stronie Javy lista obiektow klasy Employee. Dopoki przetwarzamy takie obiekty punktowo to wszystko jest ok, ale jesli chcemy w ten sposob zaktualizowac pensje wszystkim pracownikom to dostaniemy n-selectow i n-updatow, gdzie n to liczba pracownikow.

To chyba nie jest prawda. Jeżeli chcemy hurtowo zwiększyć pensje każdemu o np. 10% to możemy skorzystać z języka HQL (taki hibernetowy SQL), który udostępnia batch updates.
stencel
Posted: Friday, July 03, 2009 5:17:45 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
subieta wrote:
Nie jestem pewien, czy nie następuje tu zbytnia demonizacja problemu. Jezeli referencja w ODRA ma postać fizycznego adresu, to rzeczywiście bedzie mozliwe penetrowanie całej bazy danych przez losowo generowane referencje. Ale to mozna ukrócić np. poprzez zobowiazanie klienta np. do podania typu obiektu identyfikowanego przez referencję. To praktycznie wykluczy strzał w magmę bajtów, jeżeli typ obiektu jest jakoś w nim widoczny (powinien być). Można także sprawdzać, czy referencja wysłana przez klienta jest referencją do poczatku obiektu (co jest nieco trudniejsze, ale możliwe przy odpowiedniej organizacji skład


Mozna tez zabezpieczac sie sprytniej (istnieje zreszta nieskonczenie wiele sposobow). Np. referencję wyslaną na strone klienta wzbogacamy o sume kontrolna danych z jakas liczba zwiazana z sesja, ale znana tylko po stronie serwera. Klient nie znajac polozenia tej sumy kontrolnej w strumieniu bajtow, ani nawet liczby, z ktora ta suma musi sie zgadzac, nie ma szansy wygenrowac losowo dobrej referencji i przejrzec baze w calosci. Jesli tajna liczba i suma kontrolna ma odpowiednio dużo bitów, to szansa trafienia na chybił-trafił jest pomijalna.

Dodatkowo zyskujemy to, że takiej referencji z jednej sesji, nie da się uzyć w innej sesji (bo tam jest inna "tajna" liczba do sumy kontrolnej). W ten sposob odzyskujemy kontrole nad referencjami latajacymi wolno poza kontrola serwera bazy danych. Owszem polatać sobie może, ale nie dalej niż granice sesji bazy danych.

Genialne. Sorry za to samouwielbienie, ale naprawde mi sie ten pomysl podoba.
mdabrowski
Posted: Friday, July 03, 2009 10:22:09 PM
Rank: Member

Joined: 6/18/2009
Posts: 24
Points: -25
Location: Warszawa
stencel wrote:
referencję wyslaną na strone klienta wzbogacamy o sume kontrolna danych z jakas liczba zwiazana z sesja, ale znana tylko po stronie serwera. Klient nie znajac polozenia tej sumy kontrolnej w strumieniu bajtow, ani nawet liczby, z ktora ta suma musi sie zgadzac, nie ma szansy wygenrowac losowo dobrej referencji i przejrzec baze w calosci. Jesli tajna liczba i suma kontrolna ma odpowiednio dużo bitów, to szansa trafienia na chybił-trafił jest pomijalna.

Dodatkowo zyskujemy to, że takiej referencji z jednej sesji, nie da się uzyć w innej sesji (bo tam jest inna "tajna" liczba do sumy kontrolnej). W ten sposob odzyskujemy kontrole nad referencjami latajacymi wolno poza kontrola serwera bazy danych. Owszem polatać sobie może, ale nie dalej niż granice sesji bazy danych.

Genialne. Sorry za to samouwielbienie, ale naprawde mi sie ten pomysl podoba.


Takich komplikacji możemy wymyślać w nieskończoność. Chociażby zapakować wszystko na koniec w SHA1 dzięki czemu od ręki mamy 160 bitów co jest już sporą wartością. Po przekodowaniu na Base64 dostajemy zgrabny 27-znakowy (jeśli dobrze liczę) łańcuch bardzo łatwy do przesyłania w SBQLu w tą i z powrotem.

nina wrote:
Wlasnie na tym polega naiwnosc wspolczesnych programistow. Wiara, ze jak sie cos przykryje jakims mechanizmem (alokacja pamieci garbage collectorem), albo frameworkiem (sql hibernatem), to problemy z tym co siedzi pod spodem znikna na zawsze.

Czy to znaczy, że deklarując ArrayList<int> (lub Hashmap<String, Reference> czego byśmy potrzebowali) mam zaraz drżeć bo Out-Of-Memory-Exception czyha za rogiem?

Ale skoro tak, możemy posłużyć się przykładem indeksów. Jeśli dobrze rozumiem zasadę ich działania, można stworzyć trwały (lub nietrwały, do wyboru) obiekt który byłby regularnym obiektem ODRY (workiem). Gdy następuje wysłanie referencji do klienta, wpakowujemy w niego strukturę typu <klucz, Reference>.
Wtedy by dokonać rekonstrukcji wystarczyłaby zamiana (opierając się na wcześniejszym przykładzie):
Code:
reconstruct_ref({owner}).has.Car.color := "red"

na
Code:
((RefMap where refCode={owner}).refValue).has.Car.color:="red"

Trzeba by tylko pomyśleć nad zabezpieczeniem by nikt z zewnątrz nie mógł swobodnie przeglądać tej tablicy RefMap.
subieta
Posted: Thursday, July 09, 2009 10:37:03 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Dyskusja się zakończyła, są jakies konkluzje, ale czy jest ktoś, kto miałby ochotę to zaimplementować? Dla JOBC i NOBC. Wydaje się, że to nieduża robota, a byłby z tego ładny kawałek do artykułu na tematy tych interfejsów (ktorego ciągle nie ma).
stencel
Posted: Thursday, July 09, 2009 10:51:42 AM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
subieta wrote:
Dyskusja się zakończyła, są jakies konkluzje, ale czy jest ktoś, kto miałby ochotę to zaimplementować?


Co dokladnie zaimplementowac? LAtalo tu kilka pomyslow i wszystkie spotkaly sie z krytyka. Ktore pomysly masz wiec na mysli do implementacji?
subieta
Posted: Thursday, July 09, 2009 11:16:17 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Najpierw trzeba zaimplementować najprostszą wersję, bez zabezpieczeń. Chodzi o funkcję SBQL (reconstruct_ref, albo jakas inna ładna nazwa), która zserializowany identyfikator obiektu przesłany na stronę klienta potrafi zamienić z powrotem na identyfikator obiektu. Obiekty wirtualne na razie pomijamy, ale to może być również ciekawe zadanie (jak je serializować i deserializować - XML?). Taka funkcja może być następnie wyposażona w dodatkowe zabezpieczenia. Jestem zdania, że im prostsze tym lepsze, nie mozemy zakładać, że klient Java jest szkodnikiem-hakerem, ponieważ dostęp do b.d. ODRA będzie i tak chroniony (w tej chwili pewnie słabo, ale to może być rozwinięte). Podawanie jakichs sum kontrolnych lub tworzenie lokalnych indeksów dla udostępnionych klientom identyfikatorów wydaje się przesadą. Moim zdaniem, wystarczy wyposażyć identyfikator zwracany na strone klienta w typ (czyli sygnaturę z metabazy), a następnie funkcja reconstruct_ref bedzie ten typ sprawdzać w momencie rekonstrukcji referencji - mam nadzieje, że obecnie każdy obiekt składu ma połaczenie do swojego typu podczas runtime.

Nie wiem jak obecny JOBC/NOBC parametryzuje zdania SBQL zmiennymi Java/C#, ale jezeli takiej parametryzacji nie ma, to trzeba dorobić. Kiedyś w ICONS zrobili to moi studenci (Bogucki i Michalak), lepiej niż to zrobili geniusze z ODMG w wiązaniu Java/OQL.
mdabrowski
Posted: Thursday, July 09, 2009 6:33:32 PM
Rank: Member

Joined: 6/18/2009
Posts: 24
Points: -25
Location: Warszawa
Wziąłem się w tym tygodniu za implementację ale mam sporo z tym problemów. Ale powoli do przodu.
Zdecydowałem się na razie na najprostszą wersję. Każda przesyłana na stronę klienta referencja jest zamieniana na hash (sha1) na podstawie jego id (w następnym kroku można to skomplikować i dodać więcej zmiennych na wejście do hashowania). Ktoś mądrzejszy musiałby spojrzeć, czy moja zmiana nie burzy czegoś w DBLink czy innych obszarach gdzie wykorzystywana była klasa "RemoteReferenceResult". Na razie pary (hash, referencja) są trzymane w statycznej javowej mapie ale to wersja prototypowa. W drugim podejściu chciałbym zrobić to tak jak w indeksach, czyli trzymać tą mapę jako obiekty naszej bazy. Muszę tylko doczytać o tym jak to robione jest przy indeksach i pomyśleć o ewentualnym ograniczeniu by nikt z zewnątrz nie mógł jej przegladać.
Na razie udało mi się dodać nową metodę do parsera i leksera oraz sprawić by była rozumiana przez kontroler typologiczny (kontrolę ograniczyłem do tego, że: argumentem metody musi być StringValue a nasza metoda na pewno zwróci referencję). Teraz przede mną przebicie się przez generator bitecodu i opracowanie metody wykonującej.

subieta wrote:
Nie wiem jak obecny JOBC/NOBC parametryzuje zdania SBQL zmiennymi Java/C#

Zarówno w JOBC jak i NOBC (wzorowanym na tym pierwszym) parametryzacja metod jest jedynie, jak to określił Krzysztof, skrótem notacyjnym. Czyli wspomaga jedynie budowanie łańcucha zapytania z obiektów języka w sposób potrzebny dla SBQL-a (np. zdejmuje z programisty potrzebę formatowania liczb czy dat). Zapytanie SBQL z JOBC/NOBC jest wysyłane do ODRY jako prosty poskładany łańcuch. Jest to pewnie konsekwencja tego, że JOBC/NOBC wykorzystuje tą samą funkcjonalność po stronie serwera co CLI czyli Request o kodzie
Code:
EXECUTE_SBQL_RQST = 9; // params: source, context_module_name
Jak widzicie parametrami requestu jest tylko zapytanie i nazwa modułu. Trzeba by stworzyć nowy typ requestu który brałby zapytanie i całą tablicę różnych elementów i dopiero po stronie serwera składać wszystko w całość.
mdabrowski
Posted: Monday, February 01, 2010 4:07:25 PM
Rank: Member

Joined: 6/18/2009
Posts: 24
Points: -25
Location: Warszawa
Pozwolę sobie odświeżyć dyskusję, a to za sprawą studenta, który przy okazji realizacji projektu w oparciu o ODRĘ na studiach internetowych (przedmiot KOR) nieoczekiwanie znalazł rozwiązanie mojego (i pewnie nie tylko) problemu.
Nie jest ono super eleganckie i przejrzyste ale działa niezawodnie.

dla przykładu testm0.cli wyobraźmy sobie kolejne zapytania:

pobieramy wszystkie samochody w postaci struktur gdzie każda zaczyna się "zserializowanym" wewnętrznym identyfikatorem obiektu.
Code:
(Car as c).(serialize c, c.model, c.power ...)


następnie możemy użyć tak uzyskanej i zapisanej po stronie klienta danej w zapytaniu np:
Code:
(Car as c where ((string)(serialize c) = "58620")).c.model:="zmieniona nazwa modelu"

gdzie 58620 to przykładowa dana odzyskana w poprzednim zapytaniu.

Jak pisałem nie jest to piękne ale działa całkiem dobrze. Co o tym sądzicie?
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.204 seconds.