🚀 go-pugleaf

> Masz na myśli HQL? Wiele osób go krytykuje.

Wiele osób krytykuje Railsa

> Po pierwsze, trzeba się uczyć
> kolejnego języka, który ani nie jest łatwy ani aż tak elastyczny jak byś
> myślał.

Rozumiem, że łatwiej nauczyć się kilku dialektów SQL'a.

> Po drugie, SQL jest znacznie łatwiejszy do testowania i
> optymalizacji od HQL'a.

W czym jest łatwiejszy do testowania? Część optymalizacji myślę
(akurat nie jestem pewien) robi Hibernate znając specyfikę danego
dialektu, zna specyfikę silnika.

> Wiadomo, że pewne optymalizacje są specyficzne dla
> danego silnika. Tak samo inne cechy. Podałem ci w drugim poście przykład
> stworzenia pól sortujących się wg reguł języka polskiego i hiszpańskiego.
> Jestem ciekaw jak to zaimplementujesz w HQL aby działało też z PostgreSQL.

Co ma tworzenie tabel z hql? W Hibernate jest dodatkowe narzędzie do
tworzenia tabel ale to jest tylko pomocnik. Mapuje się raczej
stworzone tabele. W tej skali projektach raczej od tworzenia tabel,
testowania i optymalizacji są całkiem inne działy.

>
> Jak jeszcze masz złudzenia co do tego, że Hibernate nie jest niezależny od
> silnika, to proszę abyś wyraził obiektowo, bez uciekania się do
> nieprzenośnej konstrukcji SQL taką kwerendę (tu dla odmiany wziąłem
> przykład dla PostgreSQL, z artykułu  http://www.throwingbeans.org/postgresql_and_xml.html)
>
> SELECT
>       article_id, xpath_string(article_xml,'/beatles/@id') AS beatle_id
>  FROM
>       t_articles
> WHERE
>       xpath_bool(article_xml,'/beatles/beatle[@alive="yes"]');
>

Zawsze można znaleźć jakieś konstrukcje lub ficzery, które nie są
przenośne, lecz nie w tym rzecz. Jeżeli masz projekt, który wiesz na
jakim silniku będzie chodził i używał elementów danego silnika, które
nie są dostępne pod innymi silnikami to spokojnie możesz używać native
sqla. Tylko w takim przypadku gdzie ta moc ROR? Hibernate daje
możliwość mapowania poszczególnych zapytać na dowolne obiekty. RoR też
ma coś podobnego ale dużo bardziej prostego.

> Gdyby Hibernate był faktycznie zapewniał takie uniwersalne, niezależne od
> bazy mapowanie obiektowe, to by ludzie nie wymyślali projektu iBATIS,
> ktory dla odmiany opiera się na czystym SQL zapakowanym me metody
> obiektowe.
>

Z tego co mi sie wydaje to iBatis jest starszy niż Hibernate. Więc jak
czysty SQL jest taki super to poco ludzie tworzyli Hibernate. Z
drugiej strony jeżeli ActiveRecord jest taki super to poco powstał
"iBATIS for Ruby"? Twoje teoria runęła.

>> Wg mnie w ActiveRecord za dużo jest native sql'a i trzeba uważać na
>> konstrukcje aby były zgodne z różnymi dialektami.

> Podaj lepiej jakiś przykład, bo nie wiem co masz na myśli.

Całe "conditions" to zwykły SQL. Przy bardziej skomplikowanych
zapytaniach i warunkach robi się bałagan. Hibernate ma "criteria"
które można łatwo dodawać a wszystko jest parsowane pod względem
typów.


> Po pierwsze, ten facet nie rozumie, że RoR nie został zaprojektowany aby
> konkurować z wielkimi, korporacyjnymi rozwiązaniami operującymi na
> skompplikowanych strukturach tabel.

A jakie środowisko krzyczało, że jest Java killerem. Że Java umiera.
Więc jak Java umiera a Rails nie został zaprojektowany do
skomplikowanych systemów to co ma być zamiast Javy?


A tak na serio. Rails jest prostym frameworkiem do prostych systemów i
ma prostego i łatwego do nauki ORM'a. Hibernate jest skomplikowanym
ORM'em, trudnym do nauki ale też ma o wiele wiele większe możliwości.
Oczywiście też używają innych wzorców projektowych (Rails - Active
record, Hibernate - Data Mapper).

Myślę, ze gościa poruszyła pewność ludzi od Railsa, ze ich framework
jest tak wielki że ho, ho a to cała drewniana Java idzie w odstawkę.
Brakuje w tym środowisku (Rails) trochę skromności i szacunku dla
większych i starszych. Środowisko Javy docenia powiew nowych pomysłów
i przyspieszyli prace nad połączeniem języków dynamicznych z Javą.
Uznane frameworki takie jak Spring wdrażają u siebie takie pomysły jak
"konwencja nad konfiguracją". Ale wszystko odbywa się raczej po cichu.

A to, że wszystko idzie w stronę ORM'a jest raczej pewne. Pokaż mi
współczesny i sprawdzony frameowk, który nie stawia ORM'a na pierwszym
miejscu. Muszę dodać, ze sam miałem i mam wątpliwości co do wyższości
ORM'a nad nativ SQL'em  (za dużo pythonowwego SQLObejct) ale się
powoli ich pozbywam (SQLAlchemy, ActiveRecord).

--
Climbus
http://blog.netstation.pl/