Tylko jak zapisać po nowemu takie zapytanie (Postgres)
select authors.lastname, count(books.id) as bcnt
from authors inner join books on
books.author_id = authors.id
group by authors.lastname
having count(books.id) > 10;
No i jeszcze sprawa z metodą project - zwraca obiekt project, z którym nie bardzo umiem cokolwiek zrobić
[quote=wpasternak]Tylko jak zapisać po nowemu takie zapytanie (Postgres)
select authors.lastname, count(books.id) as bcnt
from authors inner join books on
books.author_id = authors.id
group by authors.lastname
having count(books.id) > 10;
No i jeszcze sprawa z metodą project - zwraca obiekt project, z którym nie bardzo umiem cokolwiek zrobić[/quote]
W ARel bedzie to pewnie cos takiego:
locations = Table(:locations)
clients = Table(:clients)
locations.join(clients).on(locations[:client_id].eq(clients[:id])).project(locations[:name], clients[:id].count).group(locations[:name])
Tylko jest to bez HAVING, jeszcze nie wykombinowałem jak tego używac, i nazwy tabel i kolumn są inne. Oczywiście to jest kod ARel nie AR 
i tutaj właśnie pojawiają się schody, używanie ARel w AR wygląda mało przyjemnie, a nie wszystko będzie można osiągnąć prostym symbolem albo hashem.
Jarek jest negatywnie nastawiony od pierwszej godziny po ogłoszenia przez DHH i Wycats’a nowiny o połączeniu zespołów.
Wszystko sie zgadza. Jest jedno ALE, musisz przepisać każdą swoją aplikacje na nowa biblioteke, a nie wzystko w Sequelu działa tak pięknie jak w AR. Tutaj masz jeszcze odpowiedź Evansa na argumenty Nick’a dlaczego ARel a nie Sequel. http://sequel.heroku.com/2010/02/06/arel-sequel-differences-part-1/ w poscie jest też link do tego co pisał Nick wcześniej. Ogólnie, ARel wejdzie do Rails prawie że transparentnie. Dopiero w 3.1 ma się zmienić API na tyle że będzie naprawde widać różnice. Nie osiągniesz tego w używając Sequela. Pozatym jest tu jeszcze problem ActiveSupport. IMHO ta biblioteka po prostu musiała powstać od nowa z myślą tylko i wyłącznie o AR.
To ja na razie podziękuje za ten nowy ActiveRecord i przywitam się z DataMapperem - ale mam nadzieję, że koniec końców stanie się to używalne
W prywatne wojny się nie wtrącam. Osobiście podzielam zdanie hipertrackera - AR dostał poprostu coś co inne bibliotki już mają, nie stworzono tutaj czegoś innowacyjnego. Mnie w Railsach od zawsze denerowało to że w sumei nie mam wyboru odnośnie ORM’a. Teraz ma się to zmienić. Nie wiem czy już się zmieniło bo nie ogarnąłem jeszcze dobrze Railsów 3.
Bardzo się ucieszę jeżeli bez żadnego bólu od tearz będę mógł podpiąć Sequela bądź DataMappera zamiast ActiveRecord’a.
Że co?
Że jak wepniesz Sequela to Ci nie będą działać domyślne helpery do form, dalej Ci się będą generować migracje AR i pewnie nie będzie poprawnie działać i18n związane z tłumaczeniami pól i/lub komunikatów błędów. I pewnie kilka innych rzeczy, o których nie pomyślałem. Dlatego przecież powstał ActiveModel 
Byłoby miło, Sequel wymiata ze składnią, używa się go o wiele milej niż AR.
Że co?[/quote]
Że jak wepniesz Sequela to Ci nie będą działać domyślne helpery do form, dalej Ci się będą generować migracje AR i pewnie nie będzie poprawnie działać i18n związane z tłumaczeniami pól i/lub komunikatów błędów. I pewnie kilka innych rzeczy, o których nie pomyślałem. Dlatego przecież powstał ActiveModel :)[/quote]
Aha. Z tym że nie wiem czy droga wybrana przez Rails 3.0 jest najbardziej właściwa. Jeśli chcesz aby Twój ORM był wspierany to i tak musi kwakać ja k ActiveRecord. A już pojawia się opór i to wśród tak bliskich konceptowo ORMów jak MongoMapper…
Możesz rzucić linka do tego oporu? Na razie się nie spotkałem, więc nie wiem jakie są minusy (sam na razie nie widzę żadnych, ale to pewnie dlatego, że nie pracowałem na razie z mongomapperem).
Co do kwakania. Interfejs, który musi być zaimplementowany w ActiveModel jest naprawdę minimalny. Dosłownie kilka metod typu new?, errors, table_name itp. (chyba, że coś się bardzo pozmieniało ;P)
Wcale nie jestem źle nastawiony do RoR3 ani do połączenia z Merbem. Jedyne, co krytykowałem to sposób w jaki podeszli do implementacji RoR3, tzn. zaczęli od złej strony. Gdyby wzięli za bazę bebechy Merba zamiast RoR2, to już od dawna by była finalna wersja Rails3. Ten Arel to jakieś ulepszenie AR, ale wciąż Sequel ma potężniejsze możliwości odnośnie RDBMS. Choć z drugiej strony, to już mi wszystko jedno, bo tu bardziej ciekawią mnie bazy nierelacyjne takie jak Neo4J (vide: port do Rails) czy MongoDB. I w tym wypadku AR, z Arelem czy bez, jest bezużyteczny.
Du^H^H^H… spekulacja!
Rails 3 jest już za rogiem. W tym przypadku nie wiem czy słusznie oceniasz efekt końcowy i sposób jego osiągniecia gdy nie posiadasz zadnego empiryczngo narzędzia aby dowieść swojej teorii oraz Rails 3.0 nie ujrzało jeszcze światła dziennego jako release.
Spekulacja? Wystarczy policzyć ile miesięcy zajęło dodanie do RoR2 tego, co już dawno było w Merbie 1.x…Popraw mnie, ale zdaje się że i teraz RoR3b1 wciąż nie ma komponentów od czasu jak wyleciały z RoR1 (bo były kompletnie spieprzone od strony implementacji, były cholernie wolne). Pytałem się przez Twittera Yehudy, ale nic nie odpowiedział, czy RoR3 ma, lub planuje mieć jakiś odpowiednik merbowych Parts. Co z tego, że można w RoR3 pod URL wpiąć aplikację Rack? Czyż RoR2 tego nie potrafi wpiąć sobie cały framework Sinatry przez metal controllers? Albo kwestia ActiveModel. Dużo szumu o nic. Merb od samego początku potrafił używać dowolnego ORM’a. RoR3 w końcu też do tego doszedł po półtora roku prac… I chyba to jeszcze nie działa w pełni. To samo obietnica pozbycia się Prototype. To tez chyba jeszcze nie działa w pełni. Poza tym już w RoR2 można było podmienić helpery JS aby korzystały z JQuery (choć za pomocą plugina). Albo koncepcja pluginów jako gemów. Merb to miał od początku. Fakt, że dodano Bundlera (i dobrze) ale dodano to równocześnie do Merba 1.x. Więc w sumie RoR3, choć idzie w dobrym kierunku, to na tle Merba nie ma się czym szczególnym pochwalić.
Chyba trochę koloryzujesz
Wystarczy policzyć? Czekam na wyliczenia w takim razie, myślę, że inni też chętnie usłyszą.
Parts można przy obecnej architekturze napisać w kilkudziesięciu linijkach. Jak będę miał trochę czasu w weekend, to mogę spróbować, zobaczymy co z tego wyjdzie.
Oczywiście, że potrafi, ale nie w tak prosty i elegancki sposób.
A to już jest demagogia dla ludzi, którzy nigdy nie spojrzeli w kod merba. Merb nie miał wsparcia dla dowolnego ORMa, tylko dla Sequela, DataMappera i AR (i oczywiście wszystkich innych ORMów z takim samym interfejsem jak którykolwiek z wymienionych). Jeżeli ORM ma inny interfejs, to np. helpery Merbowe się wypną na owego ORMa tak samo jak do tej pory robiły to helpery Railsowe.
Chyba? Source or it doesn’t exist.
Chyba? Jedyne co zapewniają Railsy 3 w kwestii integracji z javascriptem to zestaw klas i atrybutów dołączanych do generowanego HTMLa. Jak chcesz możesz sobie napisać do tego obsługę w czystym javascripcie. Nie wiem gdzie tutaj obietnica pozbycia się prototype’a może nie działać. Może chodzi Ci o to, że plik js do obsługi jquery jeszcze nie działa w pełni? Tego nie wiem, ale jeżeli nie, to tylko kwestia dni/tygodni aż ktoś to zrobi, wbrew pozorom takie bindingi są dość proste do napisania.
Przy czym dalej wtedy miałeś burdel w kodzie z powrzucanym wszędzie inline javascriptem. I nie było łatwego sposobu, żeby zaimplementować ten javascript tak jak Ty tego chcesz.
Z tego co pamiętam, to merb miał bardzo dużo problemów z gemami. Nie raz i nie dwa straciłem na rozwiązywaniu tych problemów sporo czasu. Może jestem za cienki w łokciach, ale w sieci widziałem też sporo podobnych problemów, co pozwala sugerować, że nie był to jednostkowy przypadek.
Trudno, żeby się chwalić czymś, co można dodać do dowolnego projektu napisanego w Ruby.
Przyczyna może być jedna z dwóćh, a jej zidentyfikowanie jest niezbędne do podjęcia dalszych kroków:
A tak bardziej serio: trochę za poważnie przywiązujesz się do słowa “refactor” w sensie przerabiania i ugniatania istniejącego codebase Rails. Zaciągnij sobie repo z Githuba z aktualnymi Rails 3 i zrób git blame na swoich ulubionych komponentach – bardzo niewiele znajdziesz kodu pochodzącego z aktualnych gałęzi Rails.
Bardziej od “great Rails refactor” pasowałoby “great Rails rewrite”, ale ta drobna semantyczna (w tym przypadku wyłącznie semantyczna) różnica byłaby wodą na młyn trolli piszących rzeczy w stylu “if Rails is so great, why is it being rewritten from ground-up?”. Podejrzewam że ekipa stojąca za fuzją także to przewidziała i wybrała – bardzo słusznie zresztą – mniejsze zło w postaci pojedynczego Hipertrackera trolującego na blogu Yehudy oraz na Twitterze (bez urazy, ale naprawdę gdybym Cię nie znał, czyli był na miejscu Yehudy, uznałbym Twoje wejścia na ww. serwisach za zwyczajny troling) od tysiąca bezimiennych trolli, uznających użycie słowa “rewrite” za przyznanie, że Railsy są gorsze od ich ulubionego pehape, dżango czy innego springa.
Moim zdaniem na powstawania Rails 3 należałoby bardziej patrzeć jako na kompletne przepisanie Railsów z przeszczepianiem kodu z Merba, ale wymierzone w stworzenie frameworka przechodzącego cały aktualny railsowy test suite.
I tym to tak naprawdę jest “od kuchni”.
PS. Jarek, na tym forum lurkują ludzie ze szkolenia z Railsów, jakie aktualnie prowadzę. Ludzie, którym poleciłem Twoją książkę z czystym sumieniem (nie przeczytawszy jej) jako napisaną przez kompetentnego gościa, który nie pozwoliłby sobie na napisanie książki mniej niż bardzo dobrej. Weź nie opisuj Railsów jako spieprzonego od strony programistycznej frameworka, bo mi krecią robotę w ten sposób robisz
[quote=Tomash]Przyczyna może być jedna z dwóćh, a jej zidentyfikowanie jest niezbędne do podjęcia dalszych kroków:
I tak na tle wszystkich pehapowych frameworków to Rails błyszczy jak złoto. Choć wcześniej popełniono parę błędów, to nigdy bym nie powiedział że cały RoR jest spieprzony. Choć sam przyznasz, że gdyby nie było trochę spieprzone to by, jak to napisałeś, nie było potrzebne “kompletnie przepisywanie Railsów z przeszczepaniem kodu z Merba”. Merb nie potrzebował żadnego “kompletnego przepisania z przeszczepianiem kodu z Rails”. To bardziej Rails miał co pożyczać od Merba, a nie odwrotnie.
Ale generalnie od Ror 2.3.x jest już nieźle. Zresztą sam sobie piszę jedną aplikację w Ruby 1.9 i RoR3.0b (z AR i Arelem) i jak na razie nie mogę narzekać. Czekam tylko kiedy wyjdzie RSpec 2 (dopiero v2 ma być zgodna z RoR3)
Ale po co tak marginalizowac Yehude ? Ezra sie nie wpiernicza w to juz od jakiegos czasu. To ze Engine Yards wyklada $$$ nie musi przeciez znaczyc ze panuje tam jakis absolutyzm. Zatrudniaja kompetentych inzynierow z ktorymi wspolnie podejmuja decyzje, nie wierze w to ze Ezra oprocz swoich 24 godzinnych obowiazkow prowadzenia firmy ma jeszcze na glowie wszystkie decyzje w srpawie jRuby, MRI 1.8.7, Merb i teraz Rails. Przeciez ty w swojej firmie chyba tez masz cos do powiedzenia czasami ? “Nie da sie” … albo “Zarobiony jestem”
Wystarczy policzyć? :)[/quote]
Wystarczy pomyśleć i przeczytać ze zrozumieniem. 
Kupę czasu zajęło dodawanie do RoR tego co było gotowe w Merbie. Np. kwestia optymalizacji wydajnościowej, modularność, ORM agnostic, lepszy router itp. itd.
Oczywiście, że potrafi, ale nie w tak prosty i elegancki sposób.[/quote]
No dobrze, ale to są w sumie drobiazgi, a nie jakaś zasadnicza zmiana jakościowa.
Acha, dodali wsparcie do ORM których na razie nie ma, ale które może powstaną? Bo ja nie wiem jakie inne ORM masz na myśli.
Chyba?[/quote]
A działa? No to pokaż że działa. Nawet nie ma na liście opcji w generatorze. Jest wymieniony tylko AR.
Chyba? Jedyne co zapewniają Railsy 3 w kwestii integracji z javascriptem to zestaw klas i atrybutów dołączanych do generowanego HTMLa.[/quote]
Chodziło mi o helpery, wymianę RJS aby śmigało z jQuery a nie Prototype.
Tak to zawsze można było zrobić. Tylko po co wtedy helpery?
To po co helpery? Tak zawsze można było pisać.
Przy czym dalej wtedy miałeś burdel w kodzie z powrzucanym wszędzie inline javascriptem. I nie było łatwego sposobu, żeby zaimplementować ten javascript tak jak Ty tego chcesz.[/quote]
Burdel? Chyba tylko dla podglądacza wygenerowanego kodu HTML w przeglądarce. Kogoś to obchodzi? Istotne jest to, że dobrze napisane helpery w praktyce skracają czas pracy.
Z tego co pamiętam, to merb miał bardzo dużo problemów z gemami.[/quote]
Dlatego jest Bundler który nie tylko działa z RoR3b1 ale także z Merbem 1.x. Chodzi jednak o samą koncepcję, gemami łatwiej zarządzać niż pluginami w RoR 2.x.
Merb nie mial tylu pluginow, helperow i bibliotek co Rails w momencie podejmowania decyzji. Rails natomaist mialo marke, kupe materialow, duza blogosfere, webcasty, pluginy, dzialajace produkcyjne aplikacje (ile tego bylo w tym merbie?), renome, gigantyczne community skupione wokol jednego konkretnego frameworka. Przedewszysktim juz od wersji 0.13 wdrozenia, wdrozenia i jeszcze raz wdrozenia.
Juz ci to kilka razy tlumacyzlem poltora roku temu… doprowadzenie merb’a do punktu w ktorym bylo rails to jeszcze conajmnije 3-4 lata (nie tylko w sensie stricte kodu ale calego srodowiska, wszystkich tych rzeczy ktorych nie zmienic wydajnoscia ani liniami kodu), doprowadzenie rails do punktu w ktorym byl merb, to tylko refaktoryzacja… zajelo widac ponad rok.
Ezra z DHH dobrze wiedzieli o tym ze na koncu osiagna ten sam framework w taki czy inny sposob, ale kosztem tego ze beda 2 frameworki woleli widac miec jeden, sprawny, skonsolidowany i wokol tego jednego budowac biznes. Ezra rozwija ta swoja firme hostingowa, a DHH pisze ksiazki sam zobacz ze oni juz nie sa zainteresowani budowaniem swojego programistycznego ego… ida dalej