Jarosław Zabiełło - BLOG: Tag orm

Sequel vs Active Record. Część 1 - słabości AR.

Jarosław Zabiełło — Thu, 13 Dec 2007 00:37:00 +0100

Gdy framework Ruby on Rails (dalej: RoR lub Rails) rozpoczynał swoją błyskotliwą karierę, zachwycał wszystkich prostotą i elegancją konstrukcji. Jednym z fundamentalnych modułów Railsów jest Active Record, biblioteka realizująca symulację wirtualnej bazy obiektowej, pozwalającą na pracę z relacyjnymi bazami danych za pomocą obiektów języka Ruby. Active Record (dalej AR) nie uniknął jednak kilku potknięć projektowych.

Brak parametryzowanych zapytań SQL

Kompletnie nie rozumiem po co Active Record męczy się z budowaniem całej kwerendy SQL. Po co też jego tworcy tracą czas na walkę z analizą i odpowiednim escape’owaniem znaków w danych przekazywanych do zapytania. Przecież sterownik MySQL do Rubiego bez problemu to wszystko zrobi na nich! Mało tego, używanie parametryzowanych zapytań SQL jest szybsze niż samodzielne budowanie całego stringa i wykonywanie na nim kwerendy.

Brak iteratorów

Inną tajemnicą developerów AR jest brak korzystania z iteratorów. Zamiast tego AR, z uporem godnym lepszej sprawy, przepycha przez pamięć całą listę obiektów Rubiego. Im pobieramy więcej rekordów z bazy tym więcej obiektów musimy przesłać do pamięci (bo każdemu rekordowi odpowiada jeden egzemplarz klasy Active Record). AR wrzuca więc wszystkie obiekty ORM do pamięci. Trochę to bez sensu, bo bazy danych są optymalizowane na pobieranie rekordów małymi porcjami. Grupowane pobieranie/wkładanie rekordów potrafi być nawet o dwa rzędy wielkości szybsze. Gdyby DHH i koledzy popatrzyli dokładniej na standard PEP249 Pythona a nie na chaotyczne praktyki rodem z PHP, to by takiego błędu nie popełnili.

Domyślne SELECT * i błąd w :include

Gdy AR wykonuje zapytanie komendę Model.find(:all) to domyślnie wykonuje “SELECT *...” Nie byłoby z tym problemu gdyby nie to, że MySQL nie potrafi indeksować pół typu TEXT/BLOB. Pobieranie “hurtem” wszystkich kolumn z których jedna jest tego typu, dramatycznie spowalnia bazę danych.

No dobrze, ktoś powie, że można zawsze użyć opcji :select i wybrać sobie pola jakie chcemy. Niestety to się sypie, gdy chcemy użyć opcji :include aby uzyskać LEFT OUTER JOIN. Użycie opcji :include anuluje bowiem efekt działania opcji :select. (Aby to obejść trzeba zastąpić opcję :include opcją :joins i wklepać ręcznie cały fragment SQL. Opcja :joins nie koliduje z :select).

Niespójność składni :include i :joins.

To może mała sprawa, ale razi. Dlaczego :include pozwala na stosowanie ładnego zapisy :include => [:tabela1, :tabela2] a :joins przyjmuje tylko wartość typu String, tj. czysty SQL?

Aktualizacja jednej kolumny to aktualizacja wszystkich kolumn rekordu.

To już jest bardziej denerwujące. Chcemy zmienić fragment rekordu a AR serwuje nam update na wszystkich kolumnach. Nie ma jak to obejść bez uciekania się do odpalenia czystego SQL’a. Całe szczęście że AR na to pozwala.

Brak obsługi złożonych kluczy obcych

AR domyślnie w ogóle nie obsługuje złożonych kluczy obcych (Sympatycy pythonowego Django nie mają tu też powodu do dumy, bo ich ORM również tego nie potrafi). Sytuację trochę ratuje gem/plugin composite_primary_keys ale jak to z pluginami w Rails bywa, im ich mniej tym lepiej. No chyba, że ktoś sam prosi się o kłopoty. Z jakością pluginów jest różnie i trzeba ostrożnie je dobierać.

Brak krokowego budowania warunków

To jest jedna z bardziej denerwujących rzeczy. AR gromadzi warunki w wartości do klucza/opcji :conditions. Może on przyjmować wartość typu String, Array lub Hash ale tylko jedną naraz i tylko raz. Jeśli chcemy zbudować jakiś bardziej złożony warunek, to musimy sklejać sobie ręcznie kwerendę i uważać aby sobie przypadkiem nie strzelić jakimś przypadkowym sql-injection w stopę.

Nie wiem czy jest nadzieja na szybką poprawę jakości implementacji Active Record, bo mam wrażenie że developerzy i kontrybutorzy skupieni wokół tego frameworka wolą gonić za nowymi funkcjami zamiast zatrzymać się i dopracować to, co już stworzono. Na szczęście nie trzeba czekać. Active Record doczekał się godnych następców. Najbardziej znaczące są dwa: DataMapper i Sequel. Szczególnie godny uwagi jest Sequel. Ale o tym w następnej części.

Zobacz Sequel vs Active Record. Część 2 – integracja Rails z Sequelem

Mały przegląd ORM'ów dla Rubiego

Jarosław Zabiełło — Thu, 08 Nov 2007 00:16:00 +0100

Wcześniej pisałem o dostępnych bibliotekach implementujących warstwę Widoku z modelu MVC dla Ruby on Rails. Teraz krótko o ORM’ach. Jest ich już kilka.

Active Record – podstawowy ORM używany we frameworku Ruby on Rails. Dosyć prosty, ma ładne walidacje, wywołania zwrotne (callback), obsługuje relacje między tabelami. Wadą jest stosunkowo słaba implementacja. Kod jest wciąż mało zoptymalizowany wydajnościowo i pod kątem zużycia pamięci. Brakuje wciąż parametryzowanych wywołań SQL’a, iteratorów zamiast zwracania listy obiektów, próba aktualizacji jednej kolumny w tabeli powoduje aktualizację wszystkich pól rekordu. Użycie LEFT JOIN’ów zapomocą :include powoduje że nie działa :select (zwracane są wszystkie pola). Moim zdaniem, jest tu sporo do poprawienia.

Sequel – lekki ORM przypominający składnikowo ten, stosowany w Django. W efekcie jest trochę bardziej obiektowy niż Active Record. Mniej brutalnych wstawek czystego SQL’a jak to jest w Active Record. Zostawiam sobie go na póżniej do zbadania. Możliwy konkurent dla Data Mappera (o którym niżej)

OG – ORM używany w alternatywnym do Railsów frameworku Rubiego – Nitro. Nie słyszałem aby ktoś używał go poza tym frameworkiem. Podobno są zwolennicy Nitro. Ale na razie nie spotkałem się z przekonującymi argumentami o wyższości Nitro nad Rails.

RBatis – port javowego iBatis napisany w Ruby. Teoretycznie wepnie się w dowolną strukturę, bo jest oparty na czystym SQL. Tzn. pozwala na odpowiednie zamapowanie tabel i ich pól na obiekty Rubiego. Co ciekawe, pozwala ominąć niewygodne nazwy pól tak, aby z poziomu obiektu Rubiego używać innej nazwy kolumny niż występuje w tabeli. Trudno mi coś powiedzieć o dojrzałości tego projektu, ale chyba rozwija się dosyć powoli. Trochę mnie odepchnęła informacja o tym, że wciąż nie ma zaimplementowanych joinów.

Data Mapper – na razie chyba najbardziej obiecujący ORM ktory można wpiąć w Rails zamiast/obok Active Record. Jest dużo szybszy, bo lepiej zoptymalizowano budowanie zapytań. Posiada ładniejszą, bardziej obiektową składnię niż Active Record. Zresztą sami zobaczcie:

Zoo.all(:name => 'Dallas')

# odpowiednik dla

Zoo.find(:all, :conditions => ['name = ?', 'Dallas']). 

# 'gt' znaczy większy-niż. Istnieje również 'lt' (mniejszy-niż)
Person.all(:age.gt => 30)

# 'gte' znaczy większy-lub-równy-niż. Jest też 'lte'.
Person.all(:age.gte => 30)

Person.all(:name.not => 'bob')

# Jeśli wartością w parze jest Arar, to generowany jest sql'owy warunek IN()
Person.all(:name.like => 'S%', :id => [1, 2, 3, 4, 5])

# To samo co Zoo.first(...)
Zoo[:name => 'Ft. Worth']

# To samo co Zoo.find(11)
Zoo[11]

# Przykład zwrotu NOT IN ().
Person.all(:name.not => ['bob','rick','steve'])

Poza tym Data Mapper jest wielowątkowy i domyślnie używa LEFT JOIN’ów w wypadku użycia relacji. Przeciwnie do Active Record, który nie jest odporny na wątki i wymaga jawnego użycia parametru :include aby włączył joiny (przy okazji likwidując działanie parametru :select).

(UPDATED 2007-12-16) Pod JRuby można odpalać Active Record JDBC (zobacz listę gemów: gem search -r ActiveRecord) oraz Active Hibernate.

Elastyczność Railsów

Jarosław Zabiełło — Wed, 04 Oct 2006 17:01:00 +0200

Większość osób, które zetknęły się z frameworkiem Ruby on Rails zauważyła, że domyślne ustawienia są tam tak dobrane, aby maksymalnie uprościć i zminimalizować ilość ręcznej pracy przy ustawieniach. Jeśli więc ktoś trzyma się flozofii i konwencji nazw (np. dla tabel i ich pól) będzie miał znacznie mniej dodatkowej roboty z konfiguracją frameworka do pracy. Typowa definicja modelu wyglądać może nawet tak prosto:

class User < ActiveRecord::Base
end

Powyższa definicja zakłada, że tabela w bazie nosi nazwę “users”, a jej primary key nazywa się “id”. W przeciwieństwie do innych ORM’ów, railsowy ActiveRecord nie wymaga żadnego wcześniejszego definiowania pól. Ruby bez problemu sam sobie wyciagnie wszystkie nazwy pól w sposób dynamiczny wtedy, kiedy będzie mu to potrzebne.

Nietypowe struktury

Niestety, nie zawsze jesteśmy w takiej komfortowej sytuacji, że mamy wpływ na nazewnictwo tabel i ich pól. Jednak to nie jest większym problemem, bo Rails sobie z tym radzi równie prosto.

class User < ActiveRecord::Base
  set_table_name 'uzytkownicy'
  set_primary_key 'IdUzytkownika'
end

Jak widać, dużo pracy nam nie przybyło. W tym wypadku musieliśmy tylko jawnie podać jak się nazywa nasza tabela i jak się nazywa jej klucz główny.

Korzystanie z wielu baz

W momencie tworzenia projektu aplikacji RoR generowany jest automatycznie plik konfiguracyjny zawierający połączenie do bazy danych. Przykładowy plik config/database.yml mogłby wyglądać np. tak:

default: &defaults
  adapter: mysql
  host: localhost
  encoding: utf8
  username: jakis_login
  password: jakies_haslo

development:
  database: bookstore_dev
  <<: *defaults

test:
  database: bookstore_test
  port: 3307
  <<: *defaults

production:
  database: bookstore
  socket: /var/run/mysqld/mysqld.sock
  <<: *defaults

Co robi powyższy kod? Definiuje 3 bazy: produkcyjną, roboczą i testową. (Ta ostatnia jest używana tylko do testów jednostkowych więc nie powinno się tam wstawiać żadnych istotnych danych) W w/w konfiguracji zdecydowaliśmy, że wszystkie bazy będą korzystać z MySQL >=4.1 z ustawionym wew. kodowaniem UTF-8 (zalecane). Baza produkcyjna działać będzie na Linuksie, więc zamiast portu TCP, podano uniksowy socket. Baza testowa działa na porcie 3307, a robocza na domyślnym (3306). Główna sekcja “defaults” jest wspólna dla wszystkich trzech baz zgodnie z zasadą DRY (Don’t Repeat Yourself).

Załóżmy jednak, że chcemy korzystać z dodatkowej bazy i chcemy aby z niej korzystały niektóre modele. Żaden problem. Do pliku dopisujemy tylko dodatkową definicję połączenia do innej bazy:

other:
  adapter: mysql
  host: 192.168.0.123
  database: customers
  <<: *defaults

Jak widać, możemy tą metodą tworzyć aplikację korzystającą z rozproszonych baz. (W tym wypadku baza customers leży na zupełnie innym serwerze, ale korzysta z tego samego usera i hasła.)

No dobrze, ale jak modele mają rozpoznać z jakiego połączenia korzystają? To też prosta sprawa. Domyślnym połączeniem jest to, co zdefiniowano w sekcji domyślnej. Jedynie modele, które korzystają z innego połączenia, muszą to mieć jawnie zadeklarowane w definicji, np.

class Client
  establish_connection :other
end

Model Client oraz wszystkie modele utworzone z niego na drodze dziedziczenia, będą korzystać z innego połączenia niż domyślne.

BTW, to jedna z bardziej brakujących mi cech we frameworku Django (Pylons nie ma z tym żadnego problemu). Mam nadzieję, że wkrótce to poprawią i w Django będzie można bez problemu korzystać z wielu baz.

Wspolne modele dla wielu aplikacji Rails

W tym scenariuszu mamy za zadanie stworzyć szereg aplikacji webowych korzystających z oddzielnych baz o tej samej strukturze tabel. Chcemy uniknąć powielania kodu niezbędnego dla modeli ORM. Nie mamy też czasu (ani ochoty) aby siedzieć i stworzyć definicje do wszystkich tabel wraz z wyposażeniem ich w nasze własne, dodatkowe metody uwzględniające każdą, możliwą potrzebę w przyszłości. Zamiast tego, wolimy tworzyć i rozbudowywać obiektowy opis naszej bazy dla wszystkich aplikacji w miarę ich rozwoju i wzrostu złożoności. Chcemy oby nasz model biznesowy, opisywany przez ActiveRecord, rósł stopniowo wraz ze wzrostem naszych aplikacji RoR.

Do takiego zadania, najlepiej aby wszystkie aplikacje RoR korzystały ze wspólnego repozytorium modeli. W wypadku systemów POSIX (Linux, czy MacOS-X) najprościej to rozwiązać za pomocą linków symbolicznych. Jednakże, jeśli chcemy aby nasz kod był bardziej przenośny i działał także pod Windowsami musimy inaczej podejść do tego problemu: wyniesiemy definicje naszych modeli do zewnętrznych modułów Rubiego aby domieszkowały one klasy poszczególnych modeli Rails.

Wpierw musimy dla każdej aplikacji RoR wskazać gdzie leży repozytorium z wpołdzielonymi modułami. Najlepiej wstawić do pliku conf/environment.rb zmienną globalną Rubiego o nazwie, np. $SHARED.

$SHARED = File.dirname(__FILE__)+'/../../shared/'

Konstrukcja File.dirname… jest zalecana, gdyż daje pewny i jednoznaczny dostęp do pliku bez względy na to gdzie przekopiujemy cały nasz projekt. (Identycznie należy robić pod PHP aby uniknąć problemów z ustawieniami zmiennej include_dirs. Większość pehapowego lamerstwa używa zapisu require(“plik.php”) i potem się dziwi że coś im nie działa)

Załóżmy że wcześniej mieliśmy model zdefiniowany następująco:

class Book
  set_table_name 'ksiazki'
  belongs_to :author
  def self.commented(user_id)
    self.find(:all, :conditions=>['user_id=?',user_id])
  end
end

Mamy tu więc nie tylko nazwę tabeli niezgodną z konwencją Railsów, ale także dodatkową metodę klasową. Wpierw zróbmy z tego moduł:

module BookModule
  def self.extended(c)
    c.set_table_name 'ksiazki'
    c.belongs_to :author
  end
  def commented(user_id)
    self.find(:all, :conditions=>['user_id=?',user_id])
  end
end

Kod korzystający z tego modułu przyjmie postać:

if RAILS_ENV == "development"
  load $SHARED + 'models/book.rb'
else
  require $SHARED + 'models/book.rb'
end

class Book< ActiveRecord::Base
  include BookModule
  extend BookModule
end

Górny fragment jest potrzebny jeśli chcemy aby Webrick/Mongrel w trybie development się przeładowywał podczas zmiany kodu w Ruby. “include” włącza metody instancji. Zaś “extend” włącza wszystkie emetody modułu _BookModule _do klasy jako jej metody klasowe. Zwróć uwagę, że w module nie definiowaliśmy ich jako z prefiksem self. Co prawda, efektem ubocznym tego przykładu jest to, że metoda commented() będzie możliwa do uruchomienia jako metoda zarówno instancji jak i klasy, ale to raczej nie ma żadnego znaczenia.