Welcome Guest Search | Active Topics | Members | Log In

LINQ dla języka Java Options · View
rt
Posted: Friday, March 19, 2010 12:22:44 PM
Rank: Member

Joined: 6/2/2005
Posts: 24
Points: -46
Location: mokotow
aha - oczywiscie koncepcja sbql4j jako interfejsu do innyh baz - jest dobra

tyle ze sugerowal bym jego implementacje usadowic przy jakims wiekszym projekcie javowym, gdzie bedzie dokladnie zdefiniowane co potrzeba (czyli nie musisz myslec o wszystkih scenariuszah a o jakims konkretnym) no i bedzie na to budzet
Emil
Posted: Friday, March 19, 2010 12:30:06 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
rt wrote:
a takie indeksy by podniosly uzytecznosc Twojego frameworku o rzad wielkosci i to wlasnie w kierunku jaki na pewno znajdzie uzytkownikuw. nawet takie na hybcika - na hasztablah

no to sie pomadrzylem. pozdrawiam i gratuluje jeszcze raz !


Dziękuję za uznanie i zainteresowanie projektem. Niewątpliwie odpytywanie danych z użyciem indeksów to bardzo użyteczna funkcjonalność, tyle że do działania potrzebuje najpierw składu danych. Mój projekt na razie tego nie oferuje, wszystkie dane przetwarzane w zapytaniach są "z zewnątrz". Oczywiście, można by generować indeks "w locie" tuż przed wykonaniem zapytania, jednak koszt takiej operacji zapewne przekroczył by potencjalny zysk z użycia indeksu.
Tym niemniej rozpatrzę możliwości budowy składu danych z indeksami, choć zapewne dopiero po mojej obronie, która to ze względu na duży zakres projektu rozciąga się już dość długo.
rt
Posted: Friday, March 19, 2010 12:35:33 PM
Rank: Member

Joined: 6/2/2005
Posts: 24
Points: -46
Location: mokotow
nie, nie, nie ;p z tymi indeksami to nie tak

po prostu zamiast List<Employee> robisz MyHasztableIndeksedList<Employee> i kod implementujacy operator where robi uzytek z indeksuw jakie sa w istniejacym zrudle danyh

oczywiscie pierw trzeba je zdefiniowac

w kazdym razie zrobienie czegos takiego to naprawde pikus
rt
Posted: Friday, March 19, 2010 12:37:13 PM
Rank: Member

Joined: 6/2/2005
Posts: 24
Points: -46
Location: mokotow
i cos takiego ma sens juz calkiem calkiem. beztranzakcyjna in-memory database znajdzie swoje miejsce w biz produkcji
rt
Posted: Friday, March 19, 2010 12:38:44 PM
Rank: Member

Joined: 6/2/2005
Posts: 24
Points: -46
Location: mokotow
tylko ten MyHasztableIndeksedList musi implementowac IList czy jak to sie w javie nazywa (dawno nie kodowalem w Javie)
Emil
Posted: Friday, March 19, 2010 12:51:04 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
rt wrote:
nie, nie, nie ;p z tymi indeksami to nie tak

po prostu zamiast List<Employee> robisz MyHasztableIndeksedList<Employee> i kod implementujacy operator where robi uzytek z indeksuw jakie sa w istniejacym zrudle danyh

oczywiscie pierw trzeba je zdefiniowac

w kazdym razie zrobienie czegos takiego to naprawde pikus


Podoba mi się ten pomysł. Zaimplementuję go w jednym z następnych releasów projektu.
rt
Posted: Friday, March 19, 2010 12:53:43 PM
Rank: Member

Joined: 6/2/2005
Posts: 24
Points: -46
Location: mokotow
swietnie! ciesze sie ze Cie zainspirowalem. milego dnia
subieta
Posted: Friday, March 19, 2010 7:49:11 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Pozwolę sobie dołączyć link do strony SBQL4J do stron domowych SBQL. Będzie w poniedzialek 22.03.2010.
Emil
Posted: Monday, March 22, 2010 1:08:30 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
subieta wrote:
Pozwolę sobie dołączyć link do strony SBQL4J do stron domowych SBQL. Będzie w poniedzialek 22.03.2010.

Dziękuję. Na stronie projektu jest już link zwrotny do stron domowych SBQL.
Emil
Posted: Monday, March 22, 2010 10:08:03 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
http://www.ohloh.net/p/sbql4j
Taka ciekawostka - po prawej stronie na dole jest wyliczony szacunkowy koszt napisania projektu. :)
Choć przyznam że jest nieco zawyżony, bo w źródłach jest cały kod (nieco zmodyfikowany) kompilatora Javy OpenJDK. ;)
Emil
Posted: Saturday, February 12, 2011 8:55:23 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
Stworzyłem mechanizm przetwarzania zapytań SBQL4J działający na składzie db4o, po stronie serwera. Obiekty db4o są pobierane za pomocą "lazy references", pod-obiekty są wczytywane dopiero podczas wywołania funkcji nested.
Obecnie pracuję nad integracją składniową (w tej chwili zapytanie jest przekazywane do db4o w postaci drzewa AST "ręcznie" stworzonego).
Natrafiłem na pewien problem składniowo-semantyczny, może ktoś ma ciekawy pomysł na rozwiązanie?
Otóż w db4o główne obiekty w bazie nie posiadają nazw, odpytuje się je za pomocą nazwy klasy.
Tak więc naturalną składnią dla użytkownika będzie np. zapytanie:
Code:
Emp where salary > 1000

Gdzie Emp jest nazwą klasy.
Jednak kłóci się to nieco z obecną koncepcją, gdzie używamy nazw klas w statycznym kontekście (aby uzyskać dostęp do statycznych pól i metod - tak jest w Javie co obsługuje sbql4j), albo jako wywołanie konstruktora (new Emp(...) )
Np., jeśli klasa Emp będzie miała metodę statyczną calcAvgNetSalary(List<Emp> eList) to jak jej użyć w zapytaniu? Nie chcemy jej wywoływać dla wszystkich obiektów klasy Emp, tylko jako funkcję niezwiązaną z żadnym obiektem.
Widzę kilka rozwiązań, ale żadne mi się nie podoba:
1. Próba odgadnięcia podczas kontroli typologicznej, jaka jest intencja programisty - chyba to prowadzi na rafę, ale może da się wprowadzić jasne reguły. Np. jeżeli w zapytaniu występuje nazwa klasy to sprawdź czy w całym zapytaniu wiązane są jedynie statyczne bindery pochodzące z tej nazwy. Jeżeli tak - użyj nazwy jako nazwy klasy, w przeciwnym wypadku jako nazwy obiektów.
Czyli:
Code:
Emp
- nazwa obiektów
Code:
Emp.statycznePole
- nazwa klasy
Code:
Emp.calcAvgNetSalary(Emp)
- pierwsze Emp jako nazwa klasy, drugie jako nazwa obiektu
Code:
Emp.(statycznePole, salary)
- nazwa obiektów
itd.
2. Wprowadzenie oddzielnej składni dla wywołań normalnych i statycznych. Obawiam się, że może być niestrawne dla użytkownika, bo w Javie tego nie ma i taka nowa składnia nie wprowadza nowej funkcjonalności tylko łata pewne uproszczenie wprowadzone przez twórców db4o.
3. Wprowadzenie nazw dla obiektów jako słownik <nazwaObiektu, nazwaKlasy> w bazie. Potencjalny problem z kontrolą typologiczną - słownik musi być w bazie, ale potrzebujemy go w czasie kompilacji zapytania. W porównaniu z tym, obecne rozwiązanie bazujące na nazwach klas jest bardzo wygodne - nie potrzebujemy żadnych metadanych z bazy, możemy robić dowolne zapytania nawet na pustej bazie.
Mariusz
Posted: Saturday, February 12, 2011 9:38:04 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 235
Points: 210
Location: Warsaw
Może użyć specjalnej składni oznaczającej nazwę klasy, np.
Code:

Emp#.NazwaMetodyKlasowej()


Na początku pomyślałem, że przecież analogiczny problem powinien być w LINQ. Potem skojarzyłem, że tam jest bardziej rozbudowana składnia.

Ewentualnie wprowadzić regułę, że jeżeli występuje atrybut klasowy lub metoda klasowa to ma pierwszeństwo i jest "specjalnie" traktowana - tylko czy to nie będzie zbyt skomplikowane i/lub sprzeczne z czymś innym?
stencel
Posted: Saturday, February 12, 2011 10:50:49 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Code:
Emp#.NazwaMetodyKlasowej()

Rozwiazanie Mariusza jest czysta konsekwencja podejscia SBQLowego i jako takie jest po prostu dobre. W SBQL Szef radzil uzywac przyrostka Class. To z hashem mi sie nawet bardziej podoba. Po co czynic fikcje ze klasa moze sie dowolnie nazywac, skoro i tak zawsze ma przyrostek Class?
Mariusz
Posted: Tuesday, March 08, 2011 1:56:57 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 235
Points: 210
Location: Warsaw
Znalazłem informacje o ciekawym projekcie dla Javy (Lombok), który może być użyteczny w kontekście implementacji SBQL dla Javy (modyfikacja drzew AST).
Artykuł na stronach IBM: http://www.ibm.com/developerworks/java/library/j-lombok
Emil
Posted: Tuesday, March 08, 2011 8:23:48 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
Mariusz wrote:
Znalazłem informacje o ciekawym projekcie dla Javy (Lombok), który może być użyteczny w kontekście implementacji SBQL dla Javy (modyfikacja drzew AST).
Artykuł na stronach IBM: http://www.ibm.com/developerworks/java/library/j-lombok

Ciekawy projekt, dzięki za info. Na dłuższą metę byłby dobrym rozwiązaniem zadania generowania kodu na podstawie drzew AST zapytań sbql-a. Taka warstwa abstrakcji może być istotna, jeśli uwzględnimy różne wersje języka Java, do których ma być generowany kod.
Emil
Posted: Tuesday, May 24, 2011 6:53:08 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
Po przerwie udostępniłem nową wersję projektu, wzbogaconą o integrację z obiektową bazą db4o.
Zapytania są kompilowane na kliencie i wysyłane na serwer do wykonania. Jest zapewniona mocna kontrola typologiczna i wsparcie dla indeksów db4o.
Wydajność jest zachęcająca, ok 30-40% szybciej niż przez natywny język SODA dla db4o.
Dostępny jest gotowy projekt dla środowiska eclipse z przykładami (SBQL4J_Examples_v093.zip)
http://code.google.com/p/sbql4j/downloads/list
Zachęcam do zapoznania się i testowania.
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.127 seconds.