Welcome Guest Search | Active Topics | Members | Log In

LINQ dla języka Java Options · View
Emil
Posted: Thursday, November 19, 2009 12:44:01 AM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
jacenty wrote:
Mam pytanie do przykladu:
Code:
List<Pracownik> bogaciPrac = #prac where Math.round(salary) > 4000#;

Jak ma sie nazwa klasy Java "Pracownik" do nazwy typu SBQL "prac"? Z tego co widze, do kompilacji musi byc dolaczona jakas definicja mapowania, tak?


W czasie kompilacji jest dostępna informacja o typie zmiennej 'prac'. Jest ona przetwarzana przez drugi type checker zaimplementowany na potrzeby zapytań SBQL. Z informacji uzyskanych przez niego korzysta z kolei preprocesor, dzięki czemu określony jest typ wynikowy zapytania.
Mam nadzieję, że w miarę zrozumiale się wyraziłem :)
jacenty
Posted: Thursday, November 19, 2009 8:52:07 AM
Rank: Advanced Member

Joined: 4/11/2006
Posts: 130
Points: -22
Location: Łódź
Quote:
W czasie kompilacji jest dostępna informacja...
- a skad jest ta informacja brana?
Emil
Posted: Thursday, November 19, 2009 9:27:44 AM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
jacenty wrote:
a skad jest ta informacja brana?

Z typecheckera kompilatora Javy.
mich
Posted: Thursday, November 19, 2009 8:55:03 PM

Rank: Member

Joined: 3/21/2007
Posts: 19
Points: 45
Location: UMK Toruń
mogę coś więcej usłyszeć o tym jak zmodyfikowałeś kompilator?

widziałeś może prace: "Compiler plugins can handle nested languages: AST-level expansion of LINQ queries for Java" z tej strony: http://www.sts.tu-harburg.de/~mi.garcia/

jacenty
Posted: Thursday, November 19, 2009 11:53:17 PM
Rank: Advanced Member

Joined: 4/11/2006
Posts: 130
Points: -22
Location: Łódź
Emil wrote:
jacenty wrote:
a skad jest ta informacja brana?

Z typecheckera kompilatora Javy.

Przepraszam, ale naprawde nie rozumiem, skad to "wie" typechecker.
Emil
Posted: Friday, November 20, 2009 8:49:31 AM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
mich wrote:
mogę coś więcej usłyszeć o tym jak zmodyfikowałeś kompilator?

Od wersji Javy 6 kompilator jest dostępny przez API, jako biblioteka napisana w Javie. W skład JDK wchodzi implementacja kompilatora Sun'a. Kod źródłowy tej implementacji jest dostępny tu: http://openjdk.java.net/groups/compiler/ .
Zmodyfikowałem parser, z czym miałem nieco zabawy jako że jest to parser napisany 'z palca' (żadne tam CUP, czy ANTLR). Dodałem nowy liść drzewa AST i zmodyfikowałem typechecker tak, aby uruchamiał proces kompilacji zapytań SBQL.
Następnie wypisuję kod źródłowy z rozwiniętymi zapytaniami do nowego pliku źródłowego, który można już standardowo skompilować. Po obronie, jeśli uczelnia wyrazi zgodę, opublikuję swój prototyp jako opensource. Na razie wydaje się to niemożliwe, choćby ze względu na system Plagiat.

mich wrote:
widziałeś może prace: "Compiler plugins can handle nested languages: AST-level expansion of LINQ queries for Java" z tej strony: http://www.sts.tu-harburg.de/~mi.garcia/

Nie widziałem. Po tytule domyślam się że chodzi o "mniej inwazyjną" modyfikację kompilatora. Ciekawe.

jacenty wrote:
Przepraszam, ale naprawde nie rozumiem, skad to "wie" typechecker.

No tak, ale w końcu mówimy o języku programowania z kontrolą typologiczną w trakcie kompilacji, więc chyba oczywiste że musi "wiedzieć".
subieta
Posted: Friday, November 20, 2009 9:17:35 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Emil wrote:
Na razie wydaje się to niemożliwe, choćby ze względu na system Plagiat.

Nie sądzę aby był to problem. Plagiat podaje podobieństwo z dokładnością do fraz i moze Pan latwo udowodnić, że to jest Pański wcześniejszy tekst. Podobna sytuacja jest z doktoratami, ktore w większości zawierają kawałki z wcześniej opublikowanych prac. Nie spowodowało to istotnych problemów.
Szkola (w mojej osobie) popiera jak najwcześniesze wystawiania takich prac na open source, oczywiście z podaniem referencji, w tym nazwy szkoły. Czyli w tym zakresie ma Pan pełną swobodę, zaś jedynym ograniczeniem jest to, czy jest to dostatecznie atrakcyjne, stabilne i dobrze udokumentowane.
Emil
Posted: Friday, November 20, 2009 9:36:46 AM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
subieta wrote:
Emil wrote:
Na razie wydaje się to niemożliwe, choćby ze względu na system Plagiat.

Nie sądzę aby był to problem. Plagiat podaje podobieństwo z dokładnością do fraz i moze Pan latwo udowodnić, że to jest Pański wcześniejszy tekst. Podobna sytuacja jest z doktoratami, ktore w większości zawierają kawałki z wcześniej opublikowanych prac. Nie spowodowało to istotnych problemów.
Szkola (w mojej osobie) popiera jak najwcześniesze wystawiania takich prac na open source, oczywiście z podaniem referencji, w tym nazwy szkoły. Czyli w tym zakresie ma Pan pełną swobodę, zaś jedynym ograniczeniem jest to, czy jest to dostatecznie atrakcyjne, stabilne i dobrze udokumentowane.


Dziękuję za odpowiedź. W takim razie postaram się, aby stabilna i udokumentowana wersja mojego prototypu trafiła jak najszybciej do szerokiego grona odbiorców.

Emil wrote:
jacenty wrote:
Przepraszam, ale naprawde nie rozumiem, skad to "wie" typechecker.

No tak, ale w końcu mówimy o języku programowania z kontrolą typologiczną w trakcie kompilacji, więc chyba oczywiste że musi "wiedzieć".


Być może nie do końca jasno się wyraziłem. Rozwiązywanie zapytań następuje w fazie Attribute kompilacji. Opis procesu kompilacji w wersji OpenJDK znajduje się we wspomnianym wyżej tekście p. Garcia
Miguel Garcia wrote:
The phases of the OpenJDK javac (Figure 2) are representative of those
in other compilers. Rather than describe each phase in detail (as done in [11])
we review rst the whole process, focusing afterwards on the contract between
the Annotation Processing and the Analyze and Generate phases where our plugin
gets activated. During the rst phase (Parse and Enter), externally-visible
information about each compilation unit is entered into symbol tables. Next, An-
notation processing calls one or more annotation processors which may generate
new source or class les, causing a compilation restart until no new les are created.
The last phase, Analyze and Generate encapsulates several complex stages:
(1) Attribute includes type checking and constant folding. Additionally, names,
expressions and other elements in the AST are resolved to their corresponding
type and symbol nodes. (2) Flow checks for de nite assignment to variables and
for unreachable statements, based on a class-level data
ow analysis. (3) Gener-
ics erasure is followed by (4) Desugar (e.g., simpli cation of nested and inner
classes into normal ones, expansion of \foreach"); concluding with (5) Generate.


Mam nadzieję, że to ostatecznie rozwieje Twoje wątpliwości.
Emil
Posted: Friday, November 20, 2009 11:15:11 AM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
Zauważyłem, że dotychczasowe podejścia do języka zapytań zintegrowanego z Javą rozbijają się o 2 rzeczy:
- zgodność semantyczną z Javą
- składnię podobną do LINQ (z charakterystycznym lukrem from, where, na końcu select)

Według mnie prowadzi to donikąd, bo zbudowanie języka zapytań z mocną kontrolą typów w ramach składni Javy jest przedsięwzięciem karkołomnym. Tym bardziej jest to niemożliwe w składni SBQL, gdzie np operator kropki ma zupełnie inną semantykę niż w Javie. Z kolei lukier LINQ utrudnia budowanie zagnieżdżonych zapytań, co znacznie ogranicza jego pragmatykę.

Projekty typu Quaere to IMHO mnóstwo pary wrzuconej w gwizdek, bo efektem końcowym jest dziwaczna składnia pozbawiona statycznej kontroli typologicznej.

Jak widać z mojego prototypu, można zbudować język zapytań niezależny semantycznie od wyrażeń Javy, dzięki czemu jest przestrzeń do budowania składni właściwej dla dziedziny problemowej - czyli przetwarzania kolekcji i nawigacji po grafach obiektów. Jednocześnie bezszwowo łączy się on ze standardowymi wyrażeniami Javy i zapewnia mocną kontrolę typologiczną na etapie kompilacji.

Z moich obserwacji wynika, że zmiany w standardach przemysłowych skupionych wokół Javy (np adnotacje w samym języku, ale również nowości w standardzie J2EE takie jak JPA, dependency injection) są wymuszane przez projekty open source które zostają szeroko zaakceptowane (np. XDoclet będący prekursorem adnotacji, podejście Hibernate ustandaryzowane jako JPA, Spring z dependency injection, itp.).
Kto wie, może i SBQL4J się kiedyś przyjmie i doczeka się swojego JSR-a :)
subieta
Posted: Friday, November 20, 2009 11:53:09 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Emil wrote:
Zauważyłem, że dotychczasowe podejścia do języka zapytań zintegrowanego z Javą rozbijają się o 2 rzeczy:
- zgodność semantyczną z Javą
- składnię podobną do LINQ (z charakterystycznym lukrem from, where, na końcu select)


Wg mnie to są ważne sprawy, ale istnieje trzecia rzecz, najważniejsza. Jezeli jest język zapytań, to powinna być także baz danych. Tymczasem ona właśnie nie występuje lub występuje w wersji kikutowatej. Słyszalem, ze MS zrezygnował z rozwoju LINQ4SQL. Coś im nie wyszło i zapewne chodzi o to, że złożoność mappingu położyła SQL-owe optymalizacje. W SBQL też nie jest prosto: albo decydujemy sie na bazę ODRA, i wtedy jest średnio łatwo (również z dostępem do RBD), albo budujemy własny interfejs do RBD i wtedy wpadamy w kanał, w ktory wpadli praktycznie wszyscy: niska wydajność, zgubiony optymalizator SQL, silne ograniczenia na model obiektowy i na język zapytań.
Emil
Posted: Friday, November 20, 2009 12:34:25 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
subieta wrote:
Wg mnie to są ważne sprawy, ale istnieje trzecia rzecz, najważniejsza. Jezeli jest język zapytań, to powinna być także baz danych. Tymczasem ona właśnie nie występuje lub występuje w wersji kikutowatej. Słyszalem, ze MS zrezygnował z rozwoju LINQ4SQL. Coś im nie wyszło i zapewne chodzi o to, że złożoność mappingu położyła SQL-owe optymalizacje. W SBQL też nie jest prosto: albo decydujemy sie na bazę ODRA, i wtedy jest średnio łatwo (również z dostępem do RBD), albo budujemy własny interfejs do RBD i wtedy wpadamy w kanał, w ktory wpadli praktycznie wszyscy: niska wydajność, zgubiony optymalizator SQL, silne ograniczenia na model obiektowy i na język zapytań.


Ma Profesor rację, kwestia trwałości danych jest kluczowa, jeśli mówimy o języku zapytań bazy danych.
Dla mojego rozwiązania widzę 2 kierunki rozwoju:
- Integracja z bazą danych opartej typologicznie na Javie (np. db4o). Zapytania mogłyby wyglądać następująco:
Code:
ObjectContainer db = ... ; //otwarcie połączenia do bazy db4o
List<Pracownik> bogaciPrac = #db.(Pracownik where Math.round(salary) > 4000)#;

Powyższe zapytanie mogłoby być rozwiązywane za pomocą mechanizmów db4o (np. SODA), co niesie niestety istotne ograniczenia co do samych zapytań. Większość z nich nie da się przetłumaczyć w wydajny sposób i pozostaje tylko implementacja SBA po stronie samej bazy (co jednak uważam za wykonalne).

- Integracja z ODRA. Tutaj mamy większe możliwości, jednak głównym problemem pozostaje system typologiczny, który jest znacznie bogatszy w ODRA niż w Javie. Mapowanie musiałoby gubić znaczną część semantyki (dynamiczne role, dwustronne asocjacje itp.). Jesteśmy niestety ograniczeni do klas Javy, choć efekt i tak mógłby być ciekawy. Wydaje mi się, że SBQL4J daje możliwości stworzenia znacznie mocniejszego interfejsu do ODRA niż JOBC. Mogłoby to wyglądać np. tak:
Code:
@Connection(url="...")
SBQLConnection db = ... ; //otwarcie połączenia do bazy ODRA
List<Pracownik> bogaciPrac = #((db.(emp where salary > 4000)).((firstname as fn, lastname as ln, salary as sal) group as e).(new Pracownik(e.fn, e.ln, e.sal))#;

Dzięki adnotacji @Connection możliwa jest statyczna kontrola typów (są dostępne informacje o połączeniu do bazy w czasie kompilacji),

Ew. integracja z RBD mogłaby dawać eleganckie zapytania i kontrolę typów, niestety jak Profesor wspomniał, nie do przeskoczenia jest problem optymalizacji zapytań SQL, jak i wyrażenie w nich co bardziej złożonych konstrukcji SBQL. Zapytania wyglądałyby pewnie podobnie jak w poprzednim przykładzie.
stencel
Posted: Friday, November 20, 2009 2:07:41 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Chyba jednak doszło do jakiegos nieporozumienia. Microsoft nie rezygnuje z LINQ4SQL, ktory (lubimy to lub nie) jest jednak duzym sukcesem komercyjnym. Oni zmieniaja cały LINQ i chca na nowo zrobic backend (Model designer, ktory stoi miedzy skladnia - sie nie zmieni ona - a skladem danych). Beda nowe bebechy, ale front-end zostaje ten sam.

Jesli chodzi o Jave to rzeczywiscie jej integracja z SBQL, czy kazdym innym jezykiem zapytan, jest strasznie klopotliwa ze wzgledu na (nieprzezwyciezalny jednak) impedance mismatch. Tak dwoch roznych semantycznie baz jak SBQL i Java nie da sie polaczyc, podobnie jak nie bedzie malzenstwa meduzy i jeża.

Byc moze warto przyjrzec sie innym jezykom o znacznie mniejszej niezgodnosci impedancji z SBQL niz Java. Mam na mysli jezyki, ktore maja w core wbudowane operacje na kolekcjach, jak union, filter, fold, map, zip, unzip, take, first itd. Takimi jezykami sa np. Ruby i Python. Integrujac takie jezyki ze zrodlem danych SBQL/SQL/itd mozemy osiagnac naprawde dobre wyniki [ o ile programista korzysta operacji kolekcyjnych ] bez zmiany ich skladni nawet!

Natomiast w przypadku Javy musimy sie pogodzic, ze calkowita bezszwowa integracja jest niemozliwa i jedyne co mozemy zrobic to zredukowac jej bool. Mozemy isc w kierunku maksymalizacji skutecznej kontroli typologicznej albo minimalizacji zmian w samym jezyku. Oba cele sa ze soba sprzeczne i to widac z tej dyskusji. Zaden punkt siodłowy nie usatysfakcjonuje zadnej ze stron.
Emil
Posted: Friday, November 20, 2009 3:03:50 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
stencel wrote:
Jesli chodzi o Jave to rzeczywiscie jej integracja z SBQL, czy kazdym innym jezykiem zapytan, jest strasznie klopotliwa ze wzgledu na (nieprzezwyciezalny jednak) impedance mismatch.

Nie zgadzam się z tym. Impedance mismatch występuje, gdy próbujemy połączyć różne modele danych (np. relacyjny z obiektowym). SBQL jest bardzo uniwersalny i doskonale działa na modelu danych zastosowanym w Javie, więc problem impedance mismatch nie występuje.

stencel wrote:
Tak dwoch roznych semantycznie baz jak SBQL i Java nie da sie polaczyc, podobnie jak nie bedzie malzenstwa meduzy i jeża.

Java nie jest bazą, lecz językiem programowania. Z punktu widzenia języka zapytań najbardziej istotny jest model danych na którym ma działać, w tym przypadku nie ma problemu.

stencel wrote:
Byc moze warto przyjrzec sie innym jezykom o znacznie mniejszej niezgodnosci impedancji z SBQL niz Java. Mam na mysli jezyki, ktore maja w core wbudowane operacje na kolekcjach, jak union, filter, fold, map, zip, unzip, take, first itd. Takimi jezykami sa np. Ruby i Python. Integrujac takie jezyki ze zrodlem danych SBQL/SQL/itd mozemy osiagnac naprawde dobre wyniki [ o ile programista korzysta operacji kolekcyjnych ] bez zmiany ich skladni nawet!

A po co ograniczać się do składni innych języków? Nie lepiej zastosować swoją własną i mieć pełną kontrolę nad jej semantyką? Nadawanie nowej semantyki "starej" składni dopiero przypomina dziwne związki matrymonialne... I tak trzeba rozróżnić kontekst w którym używamy zwykłych wyrażeń danego języka programowania, od kontekstu gdzie używamy zapytań. A składnia może być różna w tych kontekstach. Takie rozwiązanie zastosowałem w moim prototypie.
stencel wrote:
Natomiast w przypadku Javy musimy sie pogodzic, ze calkowita bezszwowa integracja jest niemozliwa

To zależy co ma Pan na myśli. Jak udowadnia mój prototyp, możliwe jest bezszwowe tworzenie zapytań dla dowolnych obiektów Java, z uwzględnieniem mocnej kontroli typologicznej i wydajności (natywne wiązanie nazw z obiektów Java).
stencel
Posted: Friday, November 20, 2009 3:53:40 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Emil wrote:
Nie zgadzam się z tym. Impedance mismatch występuje, gdy próbujemy połączyć różne modele danych (np. relacyjny z obiektowym). SBQL jest bardzo uniwersalny i doskonale działa na modelu danych zastosowanym w Javie, więc problem impedance mismatch nie występuje.


SBQL owszem, ale Java nie bardzo. Podstawowy tryb dzialania SBQL to wiele-obiektow-naraz, a Javy jeden-obiekt-naraz. Dlatego trudno je zintegrowac. I trzeba robic takie fikuśne sztuczki jak ta z hashem. Nie bardzo mi sie ona podoba. W moim mniemaniu, jesli widac az takie roznice skladniowe, to nie jest dobrze. Marzy mi sie integracja taka ze nie widac za bardzo roznic skladniowych i wszystko jest dosc naturalne.

Emil wrote:
Java nie jest bazą, lecz językiem programowania. Z punktu widzenia języka zapytań najbardziej istotny jest model danych na którym ma działać, w tym przypadku nie ma problemu.


Mialem na mysli baze semantyczną. Chyba jednak jest pewna roznica miedzy modelem danych Javy a SBQL... To robi jakis problem. Zwlaszcza problemem jest to, ze Java nie ma w Core przetwarzania kolekcji.

Emil wrote:
A po co ograniczać się do składni innych języków? Nie lepiej zastosować swoją własną i mieć pełną kontrolę nad jej semantyką?


Z doswiadczenia widac, ze im wieksza jest ingerencja w skladnie jezyka, tym mniejsza jest szansa na akceptacje danej technologii przez spolecznosc uzytkownikow (programistow). Jesli chcemy miec wlasna skladnie i kontrole nad semantyka, po prostu piszmy aplikacje w SBQL. Why bother with Java? Jesli jednak, sie decydujemy na integracje z Java, musimy pogodzic sie z tym ze nie bedziemy mieli pelnej kontroli nad semantyka. Dlatego pisalem o jezykach, ktore maja wbudowane, naturalne operatory kolekcyjne, dzieki ktorym bez zmiany skladni, mozemy miec database queries.

Emil wrote:
To zależy co ma Pan na myśli. Jak udowadnia mój prototyp, możliwe jest bezszwowe tworzenie zapytań dla dowolnych obiektów Java, z uwzględnieniem mocnej kontroli typologicznej i wydajności (natywne wiązanie nazw z obiektów Java).


Tak jak napisalem wczesniej, nie bardzo lezy mi to rozwiazanie, co wyrazam w dyskusji. Niestety moja krytyka nie jest konstruktywna, a nawet jest calkowicie destruktywna, bo uwazam, ze tego zrobic sie da w ogole w Javie dobrze. Dlatego nie nalezy brac sobie jej zbytnio osobiscie. Jest to raczej krytyka pomyslu integracji Javy z baza danych, ktorej ladnie sie zrobic raczej nie da.
mich
Posted: Friday, November 20, 2009 5:21:16 PM

Rank: Member

Joined: 3/21/2007
Posts: 19
Points: 45
Location: UMK Toruń
Może postaram się troche podsumować wątek, bo zaczął mieć on oznaki flame war.

1. integracja z językiem - jest tutaj kilka możliwych podejść: integracja z jakimś funkcyjnym rozszerzeniem Java; bądz też ogarniecie tego co się dzieje w Closures (polecam zajrzeć); bądz też pewnie dużo innych metod. Twoja propozycja emil nie wydaje mi się do końca przekonująca, z racji tego, że znak # mam wrażenie służy jako skrót do wywołania maszynerii podobnej do JDBC. Kawał interesującej pracy z technicznego punktu widzenia pewnie zrobiłeś jednak przy zgwałceniu kompilatora, przy całej tej pracy w kontrukcji obiektów Javowych z zapytania itp. Nawet w LINQ tego nie mają, ponieważ w .net trzeba stworzyć model na podstawie modelu bazy danych, bądz też czegokolwiek innego co też różni dziwni ludzie nazywają bazami danych (http://rshelton.com/archive/2008/07/11/list-of-linq-providers.aspx). Niestety nie wychyciłem tego, ale pewnie jakbym zobaczył to by mi się spodobało.

Generalnie integracji z językiem zapytań może być mnóśtwo. Tak jak np w db4o, bądz też gdy przychodzi do innych języków jak Python czy Ruby - tam jest zrobiony kawał bardzo fajnej roboty jeśli chodzi o integrację z językiem programowania. Generalnie to LINQ jest bardzo podobny do ORMów - jest jakby trochę wyewoluowaną tą koncepcją. Osobiście lubie tą pracę: http://www.odbms.org/download/046.01%20Friedrich%20RINQ%20Concept%20of%20a%20Ruby%20Integrated%20Query%20Language%20March%202008.PDF to poukładani tej koncepcji.

2. efektywność działania/przepisywania - akurat tutaj koncepcje LINQ-podobne troche jednak wygrywają z klasycznym ORM. Miałem gdzieś benchmarki ale pogubiłem. A jeśli chodzi o produkcje efektywnych zapytań z konstrukcji języka programowania to możę warto zajrzeć tutaj: http://www-db.informatik.uni-tuebingen.de/research/ferry

3. Generalnie integracja z Java w moim mniemaniu to tak jakby techinkala: owszem jest to ciekawa i trzeba wykazać się nielada błyskotliwością; ale większą pomysłowością będzie wymyślenie co z takiej provider-based architecture można jeszcze wycisnąć. jako przykład polecam research.microsoft.com/en-us/projects/dryadLINQ co w skórcie można określić jako LINQ2MapReduce - to był mój pomysł a Microsoft mi go ukradł :)

jak chcesz emil możemy kiedyś na skype porozmawiać i podzielić się spostrzeżeniami i wiedzą
Emil
Posted: Friday, November 20, 2009 5:22:16 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
stencel wrote:
Emil wrote:
Nie zgadzam się z tym. Impedance mismatch występuje, gdy próbujemy połączyć różne modele danych (np. relacyjny z obiektowym). SBQL jest bardzo uniwersalny i doskonale działa na modelu danych zastosowanym w Javie, więc problem impedance mismatch nie występuje.

SBQL owszem, ale Java nie bardzo. Podstawowy tryb dzialania SBQL to wiele-obiektow-naraz,


Podobnie jak podstawowy tryb działania SBQL4J, więc w czym problem?

stencel wrote:
Dlatego trudno je zintegrowac. I trzeba robic takie fikuśne sztuczki jak ta z hashem. Nie bardzo mi sie ona podoba. W moim mniemaniu, jesli widac az takie roznice skladniowe, to nie jest dobrze. Marzy mi sie integracja taka ze nie widac za bardzo roznic skladniowych i wszystko jest dosc naturalne.


Pana problem przypomina dylemat człowieka który chce zjeść ciastko i jednocześnie mieć ciastko. Skoro mamy język programowania który nie ma zapytań, to chyba naturalne że musimy je wprowadzić z nową składnią, a przynajmniej z nową semantyką "starej" składni. Tak czy siak programista musi nauczyć z tego korzystać. W drugim przypadku wcale nie musi być mu łatwiej, bo może łatwo pomylić "starą" semantykę z nową, mimo że składania pozostaje ta sama. No i pytanie, co wtedy z kompatybilnością wsteczną? Jak będą działały istniejące programy z nową semantyką?
"Sztuczka z hashem", jak Pan to określił, jest oddzieleniem kontekstu języka zapytań od dotychczasowych konstrukcji języka programowania. Konteksty te wzajemnie się uzupełniają - z jednej strony możliwe jest korzystanie ze zmiennych, typów i bibliotek Javy, z drugiej strony zapytanie umożliwia niemal dowolne przetwarzanie kolekcji i zwraca typ Javowy, więc integracja jest bezszwowa. Zresztą, w LINQ jest podobny podział kontekstów, wyznaczony nowym słowem kluczowym "from", który jest lukrem składniowym, a więc jego estetyka jest co najmniej dyskusyjna. Mimo to, jak sam Pan stwierdził, LINQ okazał się sukcesem komercyjnym, czego (na razie) nie osiągnął żaden język oparty na SBA.

stencel wrote:
Emil wrote:
Java nie jest bazą, lecz językiem programowania. Z punktu widzenia języka zapytań najbardziej istotny jest model danych na którym ma działać, w tym przypadku nie ma problemu.

Mialem na mysli baze semantyczną. Chyba jednak jest pewna roznica miedzy modelem danych Javy a SBQL... To robi jakis problem. Zwlaszcza problemem jest to, ze Java nie ma w Core przetwarzania kolekcji.

SBQL opiera się na rodzinie modeli M0-M2, model Javy w 100% da się opisać za pomocą jednego z tych modeli, więc nie widzę żadnego problemu. Jaki problem konkretnie Pan widzi? Może jakiś przykład?
Odnośnie drugiej kwestii, w Javie faktycznie nie ma pojęcia kolekcji na poziomie składniowym, kolekcje są określane poprzez obiekty implementujące interfejsy java.util.Collection i java.util.List (dla sekwencji w znaczeniu SBQL). Z punktu widzenia języka zapytań nie ma znaczenia czy kolekcję rozpoznajemy po składni języka czy po interfejsie który obiekt kolekcji implementuje.

stencel wrote:
Emil wrote:
A po co ograniczać się do składni innych języków? Nie lepiej zastosować swoją własną i mieć pełną kontrolę nad jej semantyką?


Z doswiadczenia widac, ze im wieksza jest ingerencja w skladnie jezyka, tym mniejsza jest szansa na akceptacje danej technologii przez spolecznosc uzytkownikow (programistow).

A co Pan sądzi o sukcesie LINQ? Tam ingerencja w składnie wcale nie jest mała, a jednak okazało się to do zaakceptowania przez szerokie grono programistów.

stencel wrote:
Jesli chcemy miec wlasna skladnie i kontrole nad semantyka, po prostu piszmy aplikacje w SBQL. Why bother with Java?

Zastosowanie w projektach komercyjnych obecnie istniejących prototypów języków opartych na SBQL wiąże się ze znaczenie większym ryzykiem niż użycie jednego z popularnych języków programowania. No bo co ma zrobić programista, który zachęcony przez Pana pisze program w LoXiMie i ni stąd ni zowąd wyskakuje mu SEGFAULT? Chyba tylko wyrzucić cały napisany program do kosza i zacząć pisać go od nowa w innym języku programowania. W przypadku gdy wywali mu się jakieś zapytanie w SBQL4J, może w najgorszym przypadku zastąpić je znanymi sobie, sprawdzonymi konstrukcjami.

stencel wrote:
Jesli jednak, sie decydujemy na integracje z Java, musimy pogodzic sie z tym ze nie bedziemy mieli pelnej kontroli nad semantyka.

Nadal nie wiem o co Panu chodzi, można prosić jakiś przykład, najlepiej z użyciem mojego prototypu żebyśmy nie dyskutowali abstrakcyjnie?

stencel wrote:
Dlatego pisalem o jezykach, ktore maja wbudowane, naturalne operatory kolekcyjne, dzieki ktorym bez zmiany skladni, mozemy miec database queries.

Czyli, jak rozumiem, zostawiamy starą składnię, dorabiamy nową semantykę, żeby użytkownik poczuł się "naturalniej". A co z problemami które wskazałem powyżej?

stencel wrote:
Emil wrote:
To zależy co ma Pan na myśli. Jak udowadnia mój prototyp, możliwe jest bezszwowe tworzenie zapytań dla dowolnych obiektów Java, z uwzględnieniem mocnej kontroli typologicznej i wydajności (natywne wiązanie nazw z obiektów Java).

Tak jak napisalem wczesniej, nie bardzo lezy mi to rozwiazanie, co wyrazam w dyskusji. Niestety moja krytyka nie jest konstruktywna, a nawet jest calkowicie destruktywna, bo uwazam, ze tego zrobic sie da w ogole w Javie dobrze. Dlatego nie nalezy brac sobie jej zbytnio osobiscie. Jest to raczej krytyka pomyslu integracji Javy z baza danych, ktorej ladnie sie zrobic raczej nie da.


No fakt, wiele konstruktywnego z Pana wypowiedzi nie wynika. Wyraża Pan jedynie nadzieję, że ludzie rzucą wszystko co mają i zaczną używać któregoś z prototypów SBQL. Proszę mi wierzyć, że też mam taką nadzieję. Wbrew pozorom, wcale nie jestem tak bardzo przywiązany do Javy. Jednak zanim to nastąpi, programiści muszą docenić korzyści z zastosowania podejścia stosowego, do czego, mam nadzieję, przybliży ich moje rozszerzenie Javy.
Emil
Posted: Friday, November 20, 2009 7:32:34 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
mich wrote:
1. integracja z językiem - jest tutaj kilka możliwych podejść: integracja z jakimś funkcyjnym rozszerzeniem Java; bądz też ogarniecie tego co się dzieje w Closures (polecam zajrzeć);

Fakt, sposobów jest wiele. Może spróbuję teraz uargumentować, dlaczego wybrałem taki a nie inny. Ocenę pozostawiam zainteresowanym, jednak oczekuję uwag merytorycznych.
Rozdzielenie kontekstów zapytań i standardowych wyrażeń (co zastosowałem w SBQL4) ma, wg mnie, następujące zalety:
- Kompatybilność wsteczna.
Wyrażenia nowej składnia nie jest dopuszczalna w żadnej poprzedniej wersji Javy, więc wszystkie "stare" programy będą działać tak jak do tej pory. W podobny sposób do Javy 5 dołożono adnotacje i typy generyczne.
- Nieinwazyjność.
Jak wiadomo, każdy nowy element składniowy języka musi być uwzględniony z połączeniem z dowolnymi istniejącymi elementami składniowymi. W moim podejściu nie wprowadzamy takiego elementu - zapytanie jest ostatecznie tłumaczone na standardowe wyrażenie języka Java: 'new JavaStatement(...).execute()'. Dzięki temu uniknęliśmy chaosu.
- Dowolność w tworzeniu składni / semantyki
Moim celem było stworzenie języka zapytań z uwzględnieniem cech opisanych w książce Prof. Subiety, a więc min.: ortogonalność, relatywizm, minimalność, uniwersalność, bezpieczeństwo. Aby to osiągnąć potrzebna jest składnia, która to umożliwi. Budowanie nowego języka zapytań na istniejącej składni języka imperatywnego stoi, moim zdaniem, w sprzeczności z co najmniej jedną z tych cech. Mówiąc kolokwialnie: z g...na bicza nie ukręcisz. Nawet gdyby udało się osiągnąć jakiś zgniły kompromis, to nie jest to warte zachodu. Java, jak każdy żywy język, ciągle ewoluuje i z biegiem czasu dodawane były coraz to nowe konstrukcje. Może nie każdy pamięta, ale kiedyś Java nie miała obsługi wyjątków, ani klas wewnętrznych i anonimowych które są dziś powszechnie w użyciu. Podobnie było z adnotacjami i typami generycznymi. Jakoś nikt dzisiaj nie płacze że jest tego za dużo, w porównaniu do C# składnia Javy i tak jest bardzo minimalna i elegancka.

Zabawa z closures jest może interesująca jako intelektualne i techniczne wyzwanie, ale nie bardzo widzę jak ma się ona do minimalności i relatywizmu języka opartego na tym zastosowaniu.

mich wrote:
Twoja propozycja emil nie wydaje mi się do końca przekonująca, z racji tego, że znak # mam wrażenie służy jako skrót do wywołania maszynerii podobnej do JDBC.

Nie bardzo rozumiem o co chodzi. Mógłbyś to nieco rozwinąć? W zasadzie to nie widzę związku - JDBC przyjmuje zapytanie jako String (nie ma mowy o żadnej kontroli typów) i zwraca niestrukturyzowany wynik (przynajmniej w znaczeniu obiektowym). Te wady nie występują w moim podejściu. Co do krytykowanego już #, można zamiast niego użyć jakiegoś nowego słowa kluczowego, np. SELECT. Tylko, że mój język dopuszcza aktualizowanie i tworzenie nowych obiektów, więc chyba nie jest na miejscu.

mich wrote:
Kawał interesującej pracy z technicznego punktu widzenia pewnie zrobiłeś jednak przy zgwałceniu kompilatora,

Jak już wspomniałem modyfikacja kompilatora jest niewielka i w 100% kompatybilna wstecz.

mich wrote:
przy całej tej pracy w kontrukcji obiektów Javowych z zapytania itp. Nawet w LINQ tego nie mają, ponieważ w .net trzeba stworzyć model na podstawie modelu bazy danych, bądz też czegokolwiek innego co też różni dziwni ludzie nazywają bazami danych (http://rshelton.com/archive/2008/07/11/list-of-linq-providers.aspx). Niestety nie wychyciłem tego, ale pewnie jakbym zobaczył to by mi się spodobało.

Trudno mi porównywać LINQ do mojego rozwiązania z tego powodu, że nigdy LINQ nie używałem :)

mich wrote:
Generalnie integracji z językiem zapytań może być mnóśtwo. Tak jak np w db4o, bądz też gdy przychodzi do innych języków jak Python czy Ruby - tam jest zrobiony kawał bardzo fajnej roboty jeśli chodzi o integrację z językiem programowania. Generalnie to LINQ jest bardzo podobny do ORMów - jest jakby trochę wyewoluowaną tą koncepcją. Osobiście lubie tą pracę: http://www.odbms.org/download/046.01%20Friedrich%20RINQ%20Concept%20of%20a%20Ruby%20Integrated%20Query%20Language%20March%202008.PDF to poukładani tej koncepcji.

2. efektywność działania/przepisywania - akurat tutaj koncepcje LINQ-podobne troche jednak wygrywają z klasycznym ORM. Miałem gdzieś benchmarki ale pogubiłem. A jeśli chodzi o produkcje efektywnych zapytań z konstrukcji języka programowania to możę warto zajrzeć tutaj: http://www-db.informatik.uni-tuebingen.de/research/ferry

3. Generalnie integracja z Java w moim mniemaniu to tak jakby techinkala: owszem jest to ciekawa i trzeba wykazać się nielada błyskotliwością; ale większą pomysłowością będzie wymyślenie co z takiej provider-based architecture można jeszcze wycisnąć. jako przykład polecam research.microsoft.com/en-us/projects/dryadLINQ co w skórcie można określić jako LINQ2MapReduce - to był mój pomysł a Microsoft mi go ukradł :)


W zasadzie dużo jest jeszcze do zrobienia, choćby w kierunku trwałości (pisałem już o tym wcześniej). Dzięki za ciekawe linki, na pewno poczytam.

mich wrote:
jak chcesz emil możemy kiedyś na skype porozmawiać i podzielić się spostrzeżeniami i wiedzą

Bardzo chętnie.
Emil
Posted: Monday, November 30, 2009 5:31:41 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
Emil wrote:
stencel wrote:
Mialem na mysli baze semantyczną. Chyba jednak jest pewna roznica miedzy modelem danych Javy a SBQL... To robi jakis problem. Zwlaszcza problemem jest to, ze Java nie ma w Core przetwarzania kolekcji.

SBQL opiera się na rodzinie modeli M0-M2, model Javy w 100% da się opisać za pomocą jednego z tych modeli, więc nie widzę żadnego problemu.

Zwracam honor.
Nie ma 100% zgodności, bo w SBQL nie da się zamodelować zagnieżdżonych kolekcji i tablic wielowymiarowych.
O ile dobrze rozumiem, bag( bag(1,2), bag(3,4) ) jest równoważne bag(1, 2, 3, 4), proszę mnie poprawić jeśli się mylę.
Trochę szkoda, bo tego typu konstrukcje są powszechne w popularnych językach programowania, a do takiego pretenduje SBQL.
stencel
Posted: Monday, November 30, 2009 5:45:24 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Emil wrote:
Nie ma 100% zgodności, bo w SBQL nie da się zamodelować zagnieżdżonych kolekcji i tablic wielowymiarowych.
O ile dobrze rozumiem, bag( bag(1,2), bag(3,4) ) jest równoważne bag(1, 2, 3, 4), proszę mnie poprawić jeśli się mylę.
Trochę szkoda, bo tego typu konstrukcje są powszechne w popularnych językach programowania, a do takiego pretenduje SBQL.


Nie jest tak, zle bo mozna uzyc bindera:

Code:
bag( 1(bag(1,2)), 2(bag(3,4)) )


lub [ jesli ktos nie lubi numerkow jako etykiet pól:

Code:
bag( a(bag(1,2)), b(bag(3,4)) )

subieta
Posted: Monday, November 30, 2009 6:53:52 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
stencel wrote:
Emil wrote:
Nie ma 100% zgodności, bo w SBQL nie da się zamodelować zagnieżdżonych kolekcji i tablic wielowymiarowych.
O ile dobrze rozumiem, bag( bag(1,2), bag(3,4) ) jest równoważne bag(1, 2, 3, 4), proszę mnie poprawić jeśli się mylę.
Trochę szkoda, bo tego typu konstrukcje są powszechne w popularnych językach programowania, a do takiego pretenduje SBQL.


Nie jest tak, zle bo mozna uzyc bindera:

Code:
bag( 1(bag(1,2)), 2(bag(3,4)) )


lub [ jesli ktos nie lubi numerkow jako etykiet pól:

Code:
bag( a(bag(1,2)), b(bag(3,4)) )


Wiecej powiem, jezeli jest zagnieżdzanie, to z zasady korespondencji wynika, ze musza byc operatory umozliwijace wykorzystanie tego zagnieżdzania. Jezeli elementy zagnieżdżone nie mają nazw, to wykorzystanie ich staje się niemożliwe lub wymaga specjalnych opcji syntaktycznych. Zatem, jezeli zagnieżdzamy, to elementy zagnieżdżane musimy opatrzyc nazwami (poprzez zrobienie z nich binderów) w takim przypadku nie ma zadnych ograniczen w SBQL w zakresie zagnieżdżania dowolnych struktur danych oraz tablic, w tym wielowymiarowych.
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.238 seconds.