Welcome Guest Search | Active Topics | Members | Log In

LINQ dla języka Java Options · View
Mariusz
Posted: Monday, February 02, 2009 7:14:09 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 235
Points: 210
Location: Warsaw
Znalazłem interesujące podejście do implementacji LINQ dla Javy: projekt quaere. Nie chodzi mi o możliwości, bo te są pewnie dość standardowe, ale o notacje. Tradycyjnie, aby zrealizować "prawdziwe" LINQ powinniśmy zmodyfikować kompilator Javy - co nie jest zbyt przyjemne. Innym sposobem jest przesyłanie zapytań jako String'ów, ale to ma wiele znanych wad.
Opisywane podejście wykorzystuje "sprytne" konwencje nazewnicze dla standardowych konstrukcji Javy. Przykładowe zapytanie:
Code:

Integer[] numbers={5, 4, 1, 3, 9, 8, 7, 2, 0};
Iterable<Integer> lowNumbers=
        from("n").in(numbers).
        where(lt("n",5).
        select("n");

System.out.println("All numbers that are less than five:")
for (Integer n: lowNumbers) {
    System.out.println(n);
}

Inny przykład:
Code:

// Select all customers in the Washington region
Iterable<Customer> waCustomers =
        from("c").in(entityManager.entity(Customer.class)).
        where(eq("c.getRegion()", "WA")).
        select("c");

Na pierwszy rzut oka wygląda prawie jak oryginalna składnia LINQ - oczywiście nieistniejąca w Javie. W rzeczywistości stworzono odpowiednie klasy, metody, dziedziczenia, interfejsy i pisząc zapytania mamy "prawie" składnię LINQ. Wadą jest m.in. rozdzielanie "słów kluczowych" kropką, a nie spacją.
Korzyści:
- sprawdzanie błędów już na poziomie kompilacji, a nie w czasie wykonania (jak przy przesyłaniu Stringa),
- działające udogodnienia IDE (np. podpowiadanie),
- praca ze standardowymi strukturami języka Java,
- kompatybilność z istniejącymi programami Javy,
- ...

Myślę, że można by się pokusić o podobną implementację LINQ dla Javy, ale opartą o SBA/SBQL/ODRA. Prawdopodobnie dałoby się wykorzystać dużą część istniejącego kodu ODRY. Być może ktoś byłby tym zainteresowany na pracę mgr lub może nawet wyżej (przy odpowiednim rozbudowaniu). Ja prawdopodobnie poeksperymentuję z deklaratywnym GUI.
Jak dokładniej poszukałem to znalazłem jeszcze kilka projektów bazujących na powyższym pomyśle.

Gdyby ktoś jednak był zainteresowany realizacją prawdziwego LINQ to oczywiście wymaga to modyfikacji kompilatora Javy. Interesujący może być projekt Open JDK (realizowany w oparciu o upublicznione oryginalne JDK Suna), a szczególnie grupa zajmująca się modyfikacjami kompilatora. Ciekawy przykład pokazujący m.in dodanie własnego operatora (przez modyfikację kodu źródłowego kompilatora).
mich
Posted: Monday, February 02, 2009 9:51:00 PM

Rank: Member

Joined: 3/21/2007
Posts: 19
Points: 45
Location: UMK Toruń
Całkiem ciekawie się składa, ponieważ już atakowaliśmy ten temat. Okazuje się, że w okolicy linq w javie zrobiło się już całkiem tłoczno i jest kilka ciekawszych projektów niz quaere; np.:

JAQUE - JAva integrated QUEry library
Code:

r = from(data,
        where( { Integer i => i > 5  },
            from( { Integer i => Arrays.asList(i.toString(), i.toString()) },
                select( { String i => 4 } ))));

co ciekawe powyższy kod uruchomi się dopiero w Javie 1.7, w której zapowiedzieli domknięcia.

querydsl, wycinek maila:
Quote:

Mail-to: LINQ for Java <jlinq@googlegroups.com>
Querydsl has matured and is now able to execute queries on top of
- JPA / Hibernate backends
- JDBC / SQL backends
- Java Bean based collections and lists


wyczytałem gdzieś, że wobec drogi rozwoju javy wyjściem z sytuacji integracji query language w programming language jest zrobienie odpowiednich wtyczek do IDE i mechanizmów preprocesowania kodu. Tak naprawdę przecież fomuły Microsoft LINQ też są w pewien sposób preprocesowane (nawet jest możliwe robienie teo w momencie kompilacji) i przepisywane na coś a'la Native Querys, w kształcie bardzo podobnym do tego co przedstawiłęś albo nawet tych z db4o.

Ciekawsze moim zdaniem jest powalczenie z updatem (którego w Microsoftowym linq nie ma), być może właśnie silniejszy SBQL/AOQL tutaj jest całkiem na miejscu. Ja od jakiegoś czasu zastanawiałem się nad przepisywaniem formuł języka zapytań zintegrowanego z j. programowania na coś bardziej nieskopoziomowego - ostatnio najbardziej ciekawym wydaje mi się koncepcja trwałej Software Transactional Memory jako środowiska wykonawczego dla takich formuł/zapytań.
mich
Posted: Monday, February 02, 2009 10:16:14 PM

Rank: Member

Joined: 3/21/2007
Posts: 19
Points: 45
Location: UMK Toruń
jeszcze to jest dla mnie troche nie jasne:

Mariusz wrote:
Wadą jest m.in. rozdzielanie "słów kluczowych" kropką, a nie spacją.
Korzyści:
- sprawdzanie błędów już na poziomie kompilacji, a nie w czasie wykonania (jak przy przesyłaniu Stringa),
- działające udogodnienia IDE (np. podpowiadanie),
- praca ze standardowymi strukturami języka Java,
- kompatybilność z istniejącymi programami Javy,
- ...


rozdzielnie "słów kluczowych" spacją a nie kropką w Microsoft LINQ jest troche jakby wtórne. Całe LINQ jest tak naprawde cukrem syntaktyczny i jeśli się odpowiednio postarać (m.in. formuły jako pola klasy) otrzymuje się przepisywanie w czasie kompilcji na odpowiednie programy w C#. (kiedyś nawet napisałem prosty wizualizator tego co się tam pod spodem dzieje). Ponadto architektura rozoranego C# jest o wiele bogatsza niż "rozdzielnie >>słów kluczowych<< kropką a nie spacją", poneiważ ekstensje, lambda wyrażenia, generatory oraz obiekty anonimowe (te akurat są w Javie od dawna) wprowadzają bardzo silny krok naprzód w tej dziedzinie.

U nas mamy szczrze powiedziawszy temat dosyć dobrze rozgryziony, więc jeśli ktoś chce się za to zabrać porponuje jakoś połączyć siły albo przynajmniej się skonsultować by się nie dublować
Mariusz
Posted: Monday, February 02, 2009 11:10:46 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 235
Points: 210
Location: Warsaw
Nie oceniam samych możliwości takiej, czy innej implementacji LINQ. Mnie spodobał się pomysł z wykorzystaniem standardowych konstrukcji Javy.
Czytałem też o tych pomysłach na pluginy do Eclipse'a, ale niezbyt mi się to podoba. Przypomina to dość starą koncepcję preprocesora - wymaga dedykowanych narzędzi obrabiających kod przed prawdziwą kompilacją. Takie pomysły chyba zgłaszali ludzie z db4o.
No i te nieszczęsne wyrażenia lambda. Były na początku w LINQ, ale w nowej wersji zostały zastąpione bardziej "normalną" składnią. NIe mogłem zrozumieć jak ktoś mógłby chcieć tego używać - pewnie inni mieli podobne odczucia bo je zmodyfikowali.
Quote:

rozdzielnie "słów kluczowych" spacją a nie kropką w Microsoft LINQ jest troche jakby wtórne.

W C# LINQ nie ma czegoś takiego (jest normalna spacja). Z konieczności występowało w opisywanej przeze mnie wersji Java.
Quote:

Całe LINQ jest tak naprawde cukrem syntaktyczny i jeśli się odpowiednio postarać (m.in. formuły jako pola klasy) otrzymuje się przepisywanie w czasie wykonania na odpowiednie programy w C#. (kiedyś nawet napisałem prosty wizualizator tego co się tam pod spodem dzieje). Ponadto architektura rozoranego C# jest o wiele bogatsza niż "rozdzielnie >>słów kluczowych<< kropką a nie spacją", poneiważ ekstensje, lambda wyrażenia, generatory oraz obiekty anonimowe (te akurat są w Javie od dawna) wprowadzają bardzo silny krok naprzód w tej dziedzinie.

Ja nie krytykuję LINQ - generalnie idea mi się bardzo podoba - można mieć tylko zastrzeżenia do pewnych decyzji projektowych. Myślę, że będzie to rozwijane i coraz bardziej popularne. Gdyby nie konieczność zmian w kompilatorze, już dawno by powstało też dla Javy.
mich
Posted: Monday, February 02, 2009 11:31:27 PM

Rank: Member

Joined: 3/21/2007
Posts: 19
Points: 45
Location: UMK Toruń
Mariusz wrote:
Były na początku w LINQ, ale w nowej wersji zostały zastąpione bardziej "normalną" składnią. NIe mogłem zrozumieć jak ktoś mógłby chcieć tego używać - pewnie inni mieli podobne odczucia bo je zmodyfikowali.


No to nie było tak, że one były na początku a potem zostały zastąpione - one zostały poprostu opaowane w cukier syntaktyczny który jest po prostu preprocesowany - to jest generalnie proste jeśli ma się własny kompilator porządnego języka (heh).

tutaj akurat VB (nie miałem przykładu w C# pod ręką). Formula_query jest type-safe z intelisense, natomiast native_query to jest to co faktycznie wskoczy do głównej kompilacji. LINQ to jest cukier syntatkyczny ponad właśnie takimi native querys - jeśli to nie odpowiada temu co napisałeś to ja chyba nie bardzo widze co quarere wprowadziło inszego.

Code:


Dim formula_query = From emp In db_context.Employees _ 
                        Where emp.Country = "USA" _ 
                        Select emp.FirstName, emp.LastName 
 
Dim native_query = db_context.Employees. _ 
                        Where(Function(empl) empl.Country = "USA"). _ 
                        Select(Function(empl) New With {.FirstName = empl.FirstName, .LastName = empl.LastName}) 


jeszcze dwa pytania:
1. Z czystej ciekawości chciałbym się dowiedzieć co i dlaczego nie pasuje Ci w tej architekturze
2. co to jest deklaratywne GUI?
subieta
Posted: Tuesday, February 03, 2009 8:22:40 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Kiedy pracowalem w Berlinie, byl tam taki facio-amator, ktory przerabial analogowy video recorder na urzadzenie do zapisu cyfrowego, w szczegolnosci, do backupów z komputera. Bardzo sie trudzil, stekal i wsciekal, ze ciagle temu video czegos brakowalo. Mial na tym zarobic straszna kase, bo ludzie na gwalt potrzebowali urzadzen do masowego zapisu cyfrowego.

W pewnym momencie jakas duza firma wypuscila streamery. Facio-amator nie pokazal sie wiecej w pracy, jego stanowisko z calym oprzyrzadowaniem bylo pokazywane wycieczkom jako kuriosum.

Tak mi się przypomnialo, w zwiazku z przerabianiem Javy na jezyk zaputań (pomylka celowa). W koncu przyjda profesjonalisci z forsa i zrobia z tym porzadek. Ale to nie oznacza, ze nie mozemy sie tym pobawic, na razie.
Mariusz
Posted: Tuesday, February 03, 2009 9:14:35 AM

Rank: Advanced Member

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

No to nie było tak, że one były na początku a potem zostały zastąpione - one zostały poprostu opaowane w cukier syntaktyczny który jest po prostu preprocesowany

To właśnie miałem na myśli - widocznie byli inni użytkownicy, którzy uznali pierwotną składnię/koncepcję wyrażeń lambda za cudaczną i ją zmodyfikowano.
mich wrote:

jeśli to nie odpowiada temu co napisałeś to ja chyba nie bardzo widze co quarere wprowadziło inszego.

Nie pokazywałem quarere jako rozwiązania, które wprowadza nową jakość do zapytań jako takich. Pisałem:"Nie chodzi mi o możliwości, bo te są pewnie dość standardowe, ale o notacje." Przy klasycznej implementacji technik takich jak LINQ trzeba zmodyfikować kompilator. Jeżeli nie chcemy/nie możemy/nie umiemy tego zrobić, lub nie chcemy skazywać użytkowników na korzystanie z naszego przerobionego kompilatora/preprocesora, to możemy np. użyć przekazywania zapytania przez String, co ma liczne wady. To co zaproponowali twórcy quarere też jest oczywiście półśrodkiem, ale podobało mi się sprytne wykorzystanie tego co już Java oferuje. W efekcie otrzymaliśmy pewną protezę (ale dość zgrabną), które "udaje" prawdziwe LINQ z MS C#.

mich wrote:

jeszcze dwa pytania:
1. Z czystej ciekawości chciałbym się dowiedzieć co i dlaczego nie pasuje Ci w tej architekturze

Najbardzie nie pasowały mi wyrażenia lambda. Drugą wadą była udziwniona składnia (taka od tyłu w porównaniu do SQL), ale wiem, że jest ona spowodowana wykorzystywaniem podpowiadania w IDE (chyba nie da się inaczej). I jeszcze kilka mniej ważnych rzeczy o któych teraz nie pamiętam. Ogólnie mi się podoba.
mich wrote:

2. co to jest deklaratywne GUI?

W podejściu deklaratywnym określamy co ma być zrobione, a nie mówimy dokładnie jak. Przykładem jest SQL gdzie podajemy co chcemy wiedzieć, a nie precyzyjnie jak to zrobić (porównując do klasycznego pisania programu z pętlami, warunkami, itp.). Od jakiegoś czasu staram się zastosować podobne podejście do tworzenia GUI:
- zacząłem od wykorzystania adnotacji Javy i zrealizowałem kilka działających prototypów: artykuły #2, 3, 4,
- teraz przymierzam się do osiągnięcia podobnego celu, ale za pomocą języka wysokiego poziomu zintegrowanego np. z Javą.
stencel
Posted: Tuesday, February 03, 2009 10:09:26 AM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Mariusz wrote:
W podejściu deklaratywnym określamy co ma być zrobione, a nie mówimy dokładnie jak. Przykładem jest SQL gdzie podajemy co chcemy wiedzieć, a nie precyzyjnie jak to zrobić (porównując do klasycznego pisania programu z pętlami, warunkami, itp.). Od jakiegoś czasu staram się zastosować podobne podejście do tworzenia GUI:
- zacząłem od wykorzystania adnotacji Javy i zrealizowałem kilka działających prototypów: artykuły #2, 3, 4,
- teraz przymierzam się do osiągnięcia podobnego celu, ale za pomocą języka wysokiego poziomu zintegrowanego np. z Javą.


To moze byc bardzo ciekawy temat na nasze seminarium. Moze sie umowmy ze o tym opowiesz na pierwszym w nowym semestrze. Chetnie poslucham, a na seminarium jakiegos wielkiego tloku nie ma.

stencel
Posted: Tuesday, February 03, 2009 10:11:43 AM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Code:
Integer[] numbers={5, 4, 1, 3, 9, 8, 7, 2, 0};
Iterable<Integer> lowNumbers=
        from("n").in(numbers).
        where(lt("n",5).
        select("n");

System.out.println("All numbers that are less than five:")
for (Integer n: lowNumbers) {
    System.out.println(n);
}

Mariusz wrote:
- sprawdzanie błędów już na poziomie kompilacji, a nie w czasie wykonania (jak przy przesyłaniu Stringa)


No wlasnie to mi jakos nie wyglada... Przeciez istotna nazwa "n" jest przekazywana jako String. Pewnie moge wiec tu uzyc zmiennej typu String a w niej juz, co siedzi, to tylko sam run-time wie. I cala kontrola do bani.
Mariusz
Posted: Tuesday, February 03, 2009 10:30:42 AM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 235
Points: 210
Location: Warsaw
stencel wrote:
Code:
Integer[] numbers={5, 4, 1, 3, 9, 8, 7, 2, 0};
Iterable<Integer> lowNumbers=
        from("n").in(numbers).
        where(lt("n",5).
        select("n");

System.out.println("All numbers that are less than five:")
for (Integer n: lowNumbers) {
    System.out.println(n);
}

Mariusz wrote:
- sprawdzanie błędów już na poziomie kompilacji, a nie w czasie wykonania (jak przy przesyłaniu Stringa)


No wlasnie to mi jakos nie wyglada... Przeciez istotna nazwa "n" jest przekazywana jako String. Pewnie moge wiec tu uzyc zmiennej typu String a w niej juz, co siedzi, to tylko sam run-time wie. I cala kontrola do bani.

Słusznie: powinienem napisać, że część sprawdzania wykonywana jest na poziomie kompilacji (np. numbers jest typu "iterowalnego", ale nie jestem pewien czy jest sprawdzana możliwość zastosowania warunku lt (<) do tej "kolekcji". Wydaje mi się, że początkowo w n "nic nie siedzi" - jest ona używana tylko do odwołań wewnątrz zapytania (ale oczywiście na etapie kompilacji nie jesteśmy w stanie sprawdzić, czy w części from jest to samo co w np. select).
jacenty
Posted: Tuesday, February 03, 2009 10:47:40 PM
Rank: Advanced Member

Joined: 4/11/2006
Posts: 130
Points: -22
Location: Łódź
Prawde mowiac nie widze specjalnej roznicy miedzy tym, a szeroko dostepnymi dla Javy roznorodnymi QBE/QBC. Po prostu metody sie troche inaczej nazywaja...
mich
Posted: Wednesday, February 04, 2009 12:30:45 PM

Rank: Member

Joined: 3/21/2007
Posts: 19
Points: 45
Location: UMK Toruń
jacenty wrote:
Prawde mowiac nie widze specjalnej roznicy miedzy tym, a szeroko dostepnymi dla Javy roznorodnymi QBE/QBC. Po prostu metody sie troche inaczej nazywaja...


No niestety muszę się z Tobą nie zgodzić, jacenty. Zastanówmy się: generalnie QBE/QBC można realizować tak jak np. jest to w HQL - takimi magic stringami; nie ma type-safe @design-time więc różnica jest już od razu widoczna. Przy realizacji tak jak np. w db4o natywnymi zapytaniami jest już to o krok wyżej (i nawet kropka a nie spacja jest tutaj troche wtórna). Jednakże w drugim przypadku zostaje jeszcze problem standardów i powszechności.
Gdy pracowałem w .NET dostałem kontrolkę, która dosyć mocno ora bazę danych (robi grupowania, selekcje i pracuje na dużych ilościach danych) . Jeśli query lanugage jest zintergorawny tak mocno z językiem w tedy twórcy takiej kotrnolki muszą adresować język, a nie jakiś konkretny framework pod spodem - a to przecież jest już całĸiem duża różnica. W przypadku gdyby tak nie było musiałyby być oddzielne porty tej kontrolki do różnych abstrakcyjnych języków pracującymi ponad źródłami danych, a tak po prostu kontrolka jest adresowana po prostu do języka. Mi sie generalnie to podobało bo ja tylko i wyłącznie musiałem podać źródło daneych tej kontrolce a do bazy danych trafiały już zapytania przedziałowe, z grupowaniami itd itp. w jezyku źródła danych.
jacenty
Posted: Wednesday, February 04, 2009 1:16:21 PM
Rank: Advanced Member

Joined: 4/11/2006
Posts: 130
Points: -22
Location: Łódź
Nie do konca rozumiem Twoja wypowiedz, ale to pewnie spowodowane jest po prostu niskim cisnieniem atmosferycznym. Obiecuje, ze przeczytam jeszcze raz, kiedy pogoda sie poprawi.
Emil
Posted: Monday, November 16, 2009 10:02:48 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
Dorzucę swoje 3 grosze w temacie języka zapytań dla Javy.
W ramach pracy magisterskiej implementuję rozszerzenie Javy o język zapytań oparty na SBA.
Zmodyfikowałem kompilator javy 6 tak, że akceptuje zapytania między znakami #, przykładowo:

Code:
List<Pracownik> prac = pobierzWszystkichPracownikow();
List<Pracownik> bogaciPrac = #prac where Math.round(salary) > 4000#;


W czasie działania typecheckera javy zapytanie jest parsowane, przeprowadzana jest statyczna kontrola typów w zapytaniu, rozwiązywane są nazwy z środowiska javowego (w tym przypadku 'prac' i 'Math'), określany jest typ wynikowy.
W zasadzie jest to preprocesing, więc taki kod musi być zawarty w pliku z nowym rozszerzeniem.

Będę wdzięczny za uwagi merytoryczne dot. takiego sposobu integracji. Może ktoś wpadnie na jakieś ciekawe zapytanie (na obiektach javowych), które warto by przetestować?
subieta
Posted: Tuesday, November 17, 2009 8:52:11 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Emil wrote:
Będę wdzięczny za uwagi merytoryczne dot. takiego sposobu integracji. Może ktoś wpadnie na jakieś ciekawe zapytanie (na obiektach javowych), które warto by przetestować?


Jest jeszcze troche za mało ionformacji aby podjąć dyskusję. Główne cechy, które mogą być rozpatrywane:
- pełna składnia implementowanego języka,
- jak wyniki zapytań są przekazywane do programu w Java?
- w jaki sposób traktuje się kolekcje i asocjacje (Java ma do tego celu dość prymitywne środki)?
- jaki jest stosunek nowego jezyka do bazy danych (czy w ogóle podejmuje taki temat) i do jakie bazy danych (SQL, ODRA, ...?)?
Emil
Posted: Tuesday, November 17, 2009 11:02:35 AM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
Quote:
Jest jeszcze troche za mało ionformacji aby podjąć dyskusję.

Postaram się nieco rozwinąć.
Język SBQL4J (mam nadzieję że nazwa nie jest zastrzeżona) służy do odpytywania obiektów w języku Java, jak również ich aktualizowania (poprzez wywoływanie metod i funkcji). Ponieważ jest to rozszerzenie istniejącego języka, nie definiuje nowego modelu obiektowego. W 100% opiera się na tym co jest w Javie. W związku z tym, nie podejmuje problemu trwałości. Zapytania odbywają się wyłącznie na danych w pamięci operacyjnej.

Quote:
Główne cechy, które mogą być rozpatrywane:
- pełna składnia implementowanego języka,

Składnia jest zbliżona do SBQL, zaimplementowałem 31 operatorów:
- algebraiczne: +, -. *, /, %, = (equals), != (not equals), >, <, >=, <=, OR, AND, SUM, COUNT, AVG, MIN, MAX, UNION, INTERSECT, UNIQUE, NOT, IN, STRUCT, BAG, COMMA
- niealgebraiczne: . , WHERE, , JOIN, ORDERBY, CLOSEBY

Quote:
- jak wyniki zapytań są przekazywane do programu w Java?

Poprzez preprocesing. Zapytanie jest rozwijane do normalnego wyrażenia w języku Java. Np. powyższe zapytanie:
Code:
List<Pracownik> bogaciPrac = #prac where Math.round(salary) > 4000#;

jest rozwijane do następującego wyrażenia:
Code:
List<Pracownik> bogaciPrac = (java.util.List<java.lang.Pracownik>)new pl.wcislo.sbql4j.java.utils.JavaStatement("prac where Math.round(salary) > 4000",
java.util.Arrays.asList(new pl.wcislo.sbql4j.java.utils.Pair<Object>("prac",prac)),
java.util.Arrays.asList(new pl.wcislo.sbql4j.java.utils.Pair<Class>("Math",Math.class)). execute();

Jak widać na powyższym przykładzie, w czasie kompilacji określany jest typ wynikowy zapytania, jak i przekazane są obiekty, których nazwy rozwiązane zostały jako byty Javowe (w tym przypadku zmienna 'prac' i typ 'Math')

Quote:
- w jaki sposób traktuje się kolekcje i asocjacje (Java ma do tego celu dość prymitywne środki)?

Java określa kolekcje jako obiekt, w moim rozwiązaniu jest on 'spłaszczany' i traktowany jako kolekcja wyłącznie na poziomie językowym. Np. powyższa lista obiektów prac jest traktowana jako sequence(prac(i1), prac(i2), ...). Podobnie na wyjściu zapytania, typechecker określa liczność wyniku i w razie gdy jest ona większa od pojedynczego obiektu zostaje on 'opakowany' w kolekcję odpowiedniego typu.
Co do asocjacji, w zasadzie nic nowego tu nie wymyśliłem. Powiązania między obiektami traktowane są jako jednostronne.

Quote:
- jaki jest stosunek nowego jezyka do bazy danych (czy w ogóle podejmuje taki temat) i do jakie bazy danych (SQL, ODRA, ...?)?

Nie podjąłem tego tematu. Jak wspomniałem, wszystkie operacje odbywają się na obiektach nietrwałych.
Emil
Posted: Tuesday, November 17, 2009 11:13:50 AM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
Dość rozwiniętym aspektem w mojej pracy była kwestia wydajności. Dużym kosztem jest wiązanie nazw z obiektów Javowych (refleksja), dlatego eksperymentowałem trochę z bibliotekami do manipulacji bajtkodem (ASM i CGLib). Dzięki temu wywołanie metod jest ok 10x szybsze niż w przypadku refleksji (ok 2x wolniejsze niż w przypadku natywnego wywołania).
Innym zastosowaniem wspomnianych bibliotek mogłaby być budowa emitera produkującego zapytania w postaci czystego bajtkodu, co dalej drastycznie poprawiłoby wydajność. Być może jeszcze podejmę ten temat.
Mariusz
Posted: Tuesday, November 17, 2009 12:34:04 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 235
Points: 210
Location: Warsaw
Emil wrote:
Dorzucę swoje 3 grosze w temacie języka zapytań dla Javy.
W ramach pracy magisterskiej implementuję rozszerzenie Javy o język zapytań oparty na SBA.
Zmodyfikowałem kompilator javy 6 tak, że akceptuje zapytania między znakami #, przykładowo:

Code:
List<Pracownik> prac = pobierzWszystkichPracownikow();
List<Pracownik> bogaciPrac = #prac where Math.round(salary) > 4000#;


W czasie działania typecheckera javy zapytanie jest parsowane, przeprowadzana jest statyczna kontrola typów w zapytaniu, rozwiązywane są nazwy z środowiska javowego (w tym przypadku 'prac' i 'Math'), określany jest typ wynikowy.
W zasadzie jest to preprocesing, więc taki kod musi być zawarty w pliku z nowym rozszerzeniem.

Będę wdzięczny za uwagi merytoryczne dot. takiego sposobu integracji. Może ktoś wpadnie na jakieś ciekawe zapytanie (na obiektach javowych), które warto by przetestować?

Fajny pomysł. Jeżeli dobrze rozumiem to modyfikacja kompilatora polegała na dodaniu jednego(?) elementu: #. Reszta jest odpowiednim przetwarzaniem tego co jest oznaczone hash'em. Sprytne podejście - małą modyfikacja kompilatora, a duża korzyść :)
Jeżeli chodzi o sugestie to może warto spróbować połączyć to jakoś z którąś technologi utrwalających, np. Hibernate, JPA czy JDO. Szczególnie te ostatnie wydają się interesujące bo (chyba) nie narzucają konkretnej implementacji.
Emil
Posted: Tuesday, November 17, 2009 5:34:19 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
Quote:
Fajny pomysł. Jeżeli dobrze rozumiem to modyfikacja kompilatora polegała na dodaniu jednego(?) elementu: #. Reszta jest odpowiednim przetwarzaniem tego co jest oznaczone hash'em. Sprytne podejście - małą modyfikacja kompilatora, a duża korzyść :)
Jeżeli chodzi o sugestie to może warto spróbować połączyć to jakoś z którąś technologi utrwalających, np. Hibernate, JPA czy JDO. Szczególnie te ostatnie wydają się interesujące bo (chyba) nie narzucają konkretnej implementacji.


Dokładnie, zrobiłem relatywnie niewielką modyfikację kompilatora, dzięki czemu jest on w 100% zgodny ze "starą" składnią Javy.
Co do trwałości danych, to niewątpliwie bardzo istotna kwestia, choć nie wiem czy zdążę coś konkretnego zaimplementować do planowanego terminu obrony (styczeń - luty).

EDIT: W zasadzie nie jestem przekonany, czy warto z tego robić język programowania baz danych. Java jak wiemy nie ma wielu udogodnień do tego celu. Zamiast tego, można tym zrobić natywny interfejs do obiektowych baz danych, z mocną kontrolą typów w czasie kompilacji (czego nie mają interfejsy typu JDBC). Oczywiście, pewnie sporym wyzwaniem byłoby mapowanie typów np z ODRA do Java.
jacenty
Posted: Thursday, November 19, 2009 12:19:21 AM
Rank: Advanced Member

Joined: 4/11/2006
Posts: 130
Points: -22
Location: Łódź
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?
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.213 seconds.