Welcome Guest Search | Active Topics | Members | Log In

Propozycje nowych tematów Options · View
habela
Posted: Tuesday, December 14, 2004 4:23:54 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Zapraszamy do zgłaszania w niniejszym wątku propozycji nowych tematów do zrealizowania. Zgodnie z temate forum - zakładam, że chodzi tu przede wszystkim o tematy o jasno zakrojonej koncepcji, pozwalającej myśleć o ich niedalekiej realizacji.

Korekta: Jak zwrócił uwagę pomysłodawca forum "Prace implementacyjne", warto tu również zgłaszać propozycje problemów badawczych do przedyskutowania na sąsiednim forum.

Studentów realizujących prace magisterskie z zakresu systemu ODRA zapraszam do zakładania nowych wątków (1 wątek = 1 realizowany temat). Celem jest nie tylko konsultowanie, ale także informowanie grona osób zainteresowanych projektem o postępach prac.
Emil
Posted: Wednesday, November 01, 2006 8:29:24 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
Witam,
zastanawiam się nad projektem obejmującym rozszerzenie języka Java o zapytania obiektowe (na kształt Native Queires).
Projekt umożliwiałby:
1. Wykonywanie zapytań lokalnych na kolekcjach Javy.
2. Wykonywanie zapytań na zewnętrznych źródłach danych (np na obiektowych bazach danych, źródłach XML itp).

Przykładowe zapytanie mogłoby wyglądać następująco:
Code:

List<Pracownik> prac = ...
List<Pracownik> result = new Query(#{prac.Pracownik where nazwisko='Kowalski'}).list();


W przypadku zewnętrznych źródeł danych:
Code:

SbqlDataSource source = ...
List<Pracownik> result = new Query(#{source.Pracownik where nazwisko='Kowalski'}).list();


Docelowo można by umożliwić zapytanie na wielu źródłach danych (w tym co najwyżej na jednym zewnętrznym)
Code:

SbqlDataSource source = ...
List<Pracownik> prac = ...
List<Pracownik> result = new Query(#{source.Pracownik where nazwisko = ((prac.Pracownik where imie='Jan').nazwisko)}).list();


Sposobem implementacji byłoby generowanie kodu Javy - ciąg znaków '#{...}' byłby de facto specjalnym konstruktorem przyjmującym jak argumenty samo zapytanie, jak i informację o środowisku na podstawie czego zbudowany zostałby stos środowisk.

Przykładowo:
Code:

List<Pracownik> result = new Query(#{prac.Pracownik where nazwisko='Kowalski'}).list();


Zostałoby zastąpione przed kompilacją javac czymś takim:
Code:

List<Pracownik> result = new Query(new QueryBase("prac.Pracownik where nazwisko='Kowalski'", EnvFactory.getEnv(this))).list();



Informacja o środowisku byłaby budowana za pomocą refleksji Javy. Oczywiście byłaby możliwa statyczna kontrola poprawności samego zapytania, czego zarys omówię w dalszej części. Generalnie tego typu mechanizm przypominałby sposób w jaki wprowadzono nowe funkcjonalności w Javie 5, jego niewątpliwą zaletą byłaby pełna kompatybilność bajtkodu i brak konieczności niskopoziomowych zmian w samym języku. Oczywiście takie podejście nakłada pewne ograniczenia, o czym będzie dalej.

Do zapytań możliwe byłoby wykorzystanie zmiennych będących polami obiektu wywołującego, jak i wykorzystanie metod tego obiektu. Nie byłoby możliwe wykorzystanie zmiennych lokalnych (zadeklarowanych wewnątrz bloku/metody) jak i wywołanie zapytania w statycznym kontekście. Wynika to ze specyfiki mechanizmu refleksji.

Statyczna kontrola zapytań odbywała by się przed kompilacją kompilatorem Javy. Wymagała by, aby kompilator zapytań miał informacje o samej klasie (sygnatury metod, typy pól). W przypadku zewnętrznych źródeł danych konieczny jest też dostęp do metadanych danego źródła. Wydaje mi się to wykonalne w czasie przed właściwą kompilacją kompilatorem Javy.

Zewnętrzne źródło danych byłoby interfejsem pod którym byłyby ukryte usługi typu pooling połączeń, zarządzanie transakcjami itp. Byłoby odpowiednikiem interfejsu javax.sql.DataSource używanego w J2EE.

To na razie na tyle przemyśleń, czekam na uwagi i konstruktywną krytykę :-)

Pozdrawiam,
Emil Wcisło
michal
Posted: Wednesday, November 01, 2006 9:08:56 PM

Rank: Advanced Member

Joined: 12/6/2004
Posts: 332
Points: -61
Generalnie nie jestesmy fanami rozszerzania Javy o konstrukcje
jezyka zapytan, wiec prawdopodobnie odzew bedzie mizerny.

Zadanie pierwsze przy zastosowaniu setek trikow jest byc moze do zrobienia.

Zadanie drugie jest znacznie trudniejsze, poniewaz wymaga przetlumaczenia SBQL
na SQL w taki sposob, aby mozna bylo wykorzystac optymalizator docelowej bazy danych.
Inaczej narzedzie takie bedzie bezuzyteczne. To nie jest zadanie trywialne
i o ile mi wiadomo samo w sobie moze byc tematem pracy doktorskiej.
Emil
Posted: Wednesday, November 01, 2006 10:12:53 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
Jeżeli chodzi o pkt 2 to zakładałbym że zewnętrznym źródłem danych jest obiekt zgodny z SBQL (mający możliwość wykonania na nim zapytania SBQL), posiadający odpowiednie metadane nt składu obiektów, danych koniecznych do optymalizacji, generalnie wszystko co potrzebne do wykonania zapytania. Mógłby zostać on utworzony np na podstawie pliku XML i schematu opisującego dany plik XML, lub też na podstawie połączenia z SZBD opartym na SBQL i metadanych wyciągniętych z tej bazy.

Koncepcyjnie projekt byłby platformą integracyjną, umożliwiającą łączenie różnych implementacji SBQLa, przy zachowaniu zgodności z Javą. Stanowiłby pewne rozszerzenie J2EE łatwo integrując się z istniejącą infrastrukturą co mogłoby mieć istotne znaczenie komercyjne.
michal
Posted: Wednesday, November 01, 2006 10:21:29 PM

Rank: Advanced Member

Joined: 12/6/2004
Posts: 332
Points: -61
Chyba ze tak. W takim razie nie mam wiecej uwag. Moze to byc ciekawe.
subieta
Posted: Thursday, November 02, 2006 3:34:52 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
michal wrote:
Zadanie drugie jest znacznie trudniejsze, poniewaz wymaga przetlumaczenia SBQL
na SQL w taki sposob, aby mozna bylo wykorzystac optymalizator docelowej bazy danych.
Inaczej narzedzie takie bedzie bezuzyteczne. To nie jest zadanie trywialne
i o ile mi wiadomo samo w sobie moze byc tematem pracy doktorskiej.


Zadanie jest przedmiotem pracy doktorskiej Jacka Wislickiego.
Prace sa dosc zaawansowane, ale wymagaja jeszcze wlaczenia aktualizowalnych perspektyw, ktore robi Radek Adamus. Po tym jednym z glownych problemow bedzie query modification, czyli potraktowanie perspektyw jak makrosow. Calosc jest koncepcyjnie uchwytna, ale w realizacji moze sprawic troche klopotow.

Jezeli chodzi o inny wariant native queries dla jezyka Java, to generalnie moglbym byc za, natomiast trudno mi byloby zmiesci to w istniejacych projektach (nie mamy tego w planach ani tym bardziej w obowiazkach). Bylaby wiec to praca z boku, ktora byc moze moglby jakos wspomoc z innych zrodel. Pytanie czy to nie za duzy temat jak na prace magisterska.

System typologiczny SBQL i Java bardzo sie roznia, zatem takie natywne zapytania musialyby byc ubrane w skladnie i system typow jezyka Java, co na dzien dzisiejszy wydaje mi sie zbyt ograniczone i troche potworkowate. SBQL musialby byc tez mocno okrojony. Ale moze sie myle. Na razie brakuje mi wyobrazni aby zobaczyc jak to bedzie i czy skorka warta jest wyprawki. W koncu do dzis jezyki zyja z zagniezdzonym SQL i dobrze sie maja, a native queries w db4o wygladaja jak jakis egzotyczny dziwolag (z tego co ogladalem).
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.083 seconds.