ruby-mine

Sequel ist wohl die DB-Zugriffsschicht, mit der sich die wenigsten Rubyisten auskennen. Dabei ist sie meiner Meinung nach die beste reine Skripting-Bibliothek von allen dreien. Das äussert sich schon darin, dass Sequel mit keinerlei Core-Extensions wie ActiveSupport oder Extlib daher kommt. Einige werden zwar optional mitgeliefert, aber nicht standardmässig geladen.

Wie bereits erwähnt, beschäftigt sich Sequel nur mit SQL und das mit nur minimalen Abstraktionen - Sequel ist also kein ORM. Dafür kommt Sequel mit der größten Anzahl an Datenbank-Adaptern, momentan über 20. Implementierungen für verschiedene Connection-Pooling-Strategien und Sharding finden sich auch.

Plugins gibt es für viele interessante SQL-Funktionen, zum Beispiel für Windows (also, nicht das OS) oder Recursive Table Expressions.

Darüber hinaus kommt Sequel mit einem Kommandozeilentool, dass sich als Ersatz für den datenbankspezifischen Client verwenden lässt, allerdings im Grunde nur IRB mit vorgeladener Datenbank ist.

Setup

Sequel kommt komplett mit allen Plugins in einem Gem, eventuell benötigte Datenbankkonnektoren sind dabei ausgenommen. Wer also zum Beispiel sqlite3 verwenden will, benötigt also noch den sqlite3-gem oder alternativ data_objects und do_sqlite3.

Am Anfang steht wie immer `require`, bei Sequel gibt es da eigentlich nur 2 Varianten: core oder mit Modelschicht. Hierbei ist zu beachten, dass sequel standardmässig die Modelschicht mitlädt, core ist der Sonderwunsch.

1
2

require 'sequel'
require 'sequel-core'

Die Datenbankverbindung stellt man über Connection-Strings her:

1
2

db = Sequel.connect 'postgres://postgres@localhost/my_example?encoding=utf8',
        :max_connections => 10, :logger => Logger.new('log/db.log')

Wer schnell nur ein wenig rumspielen will, kann eine der convenience-Methoden verwenden, am praktischsten ist #sqlite, das sofort eine SQLite-DB im Speicher erstellt.

db = Sequel.sqlite

Extrem praktisch, wenn man nur mal schnell rumspielen will.

Queries

Sequel lebt vor allem von einem Objekt: Dataset. Datasets repräsentieren die Beschreibung eines Datensatzes (also, einen SQL-Query ;)) und können beliebig weiter verwendet und manipuliert werden. Dazu besitzen sie verschiedene Methoden, die dann einen Query auslösen. Datasets werden in der Anwendung immer durch das Datenbank-Objekt erstellt:

 people = db[:persons] #alternativ db.from(:persons)

Gibt uns einen Query für alle Zeilen der Tabelle “persons”. Ausgeführt wird der Query, wenn wir irgendeine Methode aufrufen, die auf Elemente des Datasets zugreift:

1
2
3

people.all #=> hoffentlich steckt dahinter nicht die Weltbevölkerung
people.first #=> der erste
people[:age => 13] #=> alle, die endlich auf rubyforen.de dürfen

Manipulationen eines Dataset-Objekts sind nicht-destruktiv und geben immer ein neues Dataset zurück:

1
2

children = people.filter { age < 13 }
silver_surfers = people.filter { age > 65 }

Gegenüber handgeschriebenen WHERE-Conditions hat die Filter-Methode auch den Vorteil, dass sie beliebig häufig aufgerufen werden kann:

male_silver_surfers = silver_surfers.filter(:sex => :male)

Ähnlich lassen sich SELECTs und andere Klauseln hinzufügen:

male_silver_surfers.select(:age, :sex)

Als letztes Stück Code Einführung möchte ich noch 2 Beispiele aus der Doku zeigen, JOINs und Graphing:

1
2
3
4
5

DB[:items].join(:order_items, :item_id => :id)
=> {:id=>order_items.id, :item_id=>order_items.item_id}

DB[:items].graph(:order_items, :item_id => :id).first
=> {:items=>{:id=>items.id}, :order_items=>{:id=>order_items.id, :item_id=>order_items.item_id}}

Sequel kann also die flachen Rückgaben von JOINs wieder zu geschachtelten Strukturen verwandeln. Eine äusserst praktische Funktion, die es einem erspart, diese Verbindungen selbst wieder aus dem Result zu ziehen.

Ab hier übergebe ich an die Doku, die Queries sehr genau beschreibt. Es gibt da noch viel zu finden.

Das interessante an Sequel-Datasets ist weniger, dass sie eine schöne DSL zum schreiben von SQL-Queries sind, sondern eher ihre Eigenschaft, beliebig weitergefiltert und verfeinert werden zu können. Statt also in meiner Applikation halbfertige SQL-Strings rumzureichen bietet Sequel einen manipulierbaren Datentyp und verwaltet alle Klauseln für den Nutzer und bleibt dabei so datenbankunabhängig wie möglich.

Die beschreibende Rolle von Datasets nutzt Sequel für einen eleganten ORM-Mechanismus, der einem die Arbeit mit rohen Datensets weiter vereinfacht: Sequel::Model.

Models

Sequel Models sind eigentlich ein Dekorator über einem Datenset. Zuerst mal sehen sie nicht anders aus als die, die man aus ActiveRecord kennt:

1
2
3

class People < Sequel::Model

end

Wer eine andere Tabelle mit etwas Zucker haben will, kriegt sogar ein kleines Stückchen Ruby-Magie präsentiert:

1
2
3

class People < Sequel::Model(:my_table)

end

Fängt man aber mit den Abfragen an, wird schnell klar, dass diese Models eigentlich nur aufgehübschte Datasets sind:

People.filter(:name => "Daniel").first

Wenig verwunderlich lassen sich also z.B. sehr einfach Models über gefilterten Datasets implementieren:

1
2
3
4
5
6
7

class SilverSurfers < Sequel::Model
  set_dataset DB[:people].filter ("age > ?", 65)

  def besitzt_internet_ab_60?
    # logik
  end
end

Assoziationen und Validierungen werden auch unterstützt, sollen hier aber nicht vorgestellt werden. Wer eine Lib dafür kennt, kennt sie alle.

Wer die Dataset-API kennt, kommt mit Models sofort zurecht. Sequels einziger zusätzlicher Job ist hier das Mapping roher Datenbankantworten auf Objekte.

Fazit

Sequel in einem Satz: Angenehmer als SQL, sehr featurereich und sehr fokussiert. Wer alles aus seiner SQL-Datenbank herausholen will oder Skripte schreibt, die komplexe Transformationen der Datenbank durchführen müssen ist mit Sequel sehr gut bedient. Darüber hinaus ist die Bibliothek vorzüglich dokumentiert, solange man weiss, was hinter den SQL-Konzepten steckt. Wer den Unterschied zwischen WHERE und HAVING nicht kennt, wird hier auch nicht schlauer. Die Modelschicht ist zwar ein klein wenig spartanisch, bringt aber alles, was man sich so wünscht. Wer sich nur für Objektmodellierung und nicht für SQL interessiert, greift hier besser zu anderen Lösungen. Wer im großen Stil die Features von SQL-Datenbanken ausnutzt, wird hier schnell fündig und glücklich, da Sequel hier wenige Umwege zum Ziel einbaut.

Zuletzt: Jeremy Evans “Blog II” (Das Sequel zu Blog ;) ) ist sehr lesenswert, vor allem für jeden, der sich für SQL interessiert. Und solltet ihr Jeremy auf einer Konferenz treffen: sprecht mit ihm, man trifft selten nettere und kompetentere Programmierer.