Händler-Anwendung (Ruby-on-Rails-Beispiel): Unterschied zwischen den Versionen
Kowa (Diskussion | Beiträge) |
Kowa (Diskussion | Beiträge) |
||
| Zeile 187: | Zeile 187: | ||
... | ... | ||
</source> | |||
Nun werden die Attribute in die zugehörigen <code>migrate</code>-Dateien eingefügt. | |||
<source lang="bash"> | |||
vi /web/rails/haendler/db/migrate/*_create_haendler.rb | |||
</source> | |||
<source lang="ruby"> | |||
class CreateHaendler < ActiveRecord::Migration | |||
def self.up | |||
create_table :haendler do |t| | |||
t.string :name, :null => false | |||
t.string :adresse | |||
t.timestamps | |||
end | |||
end | |||
def self.down | |||
drop_table :haendler | |||
end | |||
end | |||
</source> | |||
<source lang="bash"> | |||
vi /web/rails/haendler/db/migrate/*_create_waren.rb | |||
</source> | |||
<source lang="ruby"> | |||
class CreateWaren < ActiveRecord::Migration | |||
def self.up | |||
create_table :waren do |t| | |||
t.string :typ | |||
t.string :bezeichnung | |||
t.timestamps | |||
end | |||
end | |||
def self.down | |||
drop_table :waren | |||
end | |||
end | |||
</source> | |||
<source lang="bash"> | |||
vi /web/rails/haendler/db/migrate/*_create_liefern.rb | |||
</source> | |||
<source lang="ruby"> | |||
class CreateLiefern < ActiveRecord::Migration | |||
def self.up | |||
create_table :liefern do |t| | |||
# numeric(6,2) wird von Rails nicht direkt unterstützt | |||
t.column :preis, 'numeric(6,2)' | |||
t.integer :lieferzeit, :null => false | |||
t.timestamps | |||
end | |||
end | |||
def self.down | |||
drop_table :liefern | |||
end | |||
end | |||
</source> | </source> | ||
Version vom 8. Dezember 2008, 14:17 Uhr
Dieser Artikel wird derzeit von einem Autor gründlich bearbeitet. Die Inhalte sind daher evtl. noch inkonsistent.
Zweck
Anhand einer einfachen Web-Anwendung sollten die Prinzipien von Ruby on Rails erläutert werden.
Diesem Beispiel liegt die Händler-Datenbank zugrunde, die Wolfgang Kowarschick in der Vorlesung Datenmanagement II (Multimedia-Datenbanksysteme)[1] als Beispiel einsetzt:
Voraussetzungen
Folgende Softwarepakete wurden installiert:
- Apache 2.2.x
- PostgreSQL 8.x (am Besten zusammen mit einem Frontend wie z.B phpPgAdmin)
- Ruby 1.8.7
- Ruby on Rails
Ruby on Rails wurde zusammen mit einigen Erweiterungs-Modulen mit Hilfe des Ruby-Paketmanagers gem installiert:
RUBY_DIR=...; export RUBY_DIR
POSTGRESQL_DIR=...; export POSTGRESQL_DIR
gem install rails --include-dependencies
gem install postgres -r -- --with-pgsql-dir=${POSTGRESQL_DIR}
gem install passenger
${RUBY_DIR}/bin/passenger-install-apache2-module
Auf dem Test-Server steht in der Datei /etc/hosts ein
Eintrag für den gewünschten virtuellen Server, auf dem die Anwendung laufen soll (die IP-Adresse
und der Rechnernamen können natürlich angepasst werden):
192.168.0.161 haendler.kowa haendler
Diese IP-Adresse ist einem echten oder virtuellen Rechner zugeordnet.
Unter SuSE 11 kann man einem Rechner ganz einfach mehrere IP-Adressen zuordnen.
Man trägt die neue IP-Adresse in die Datei /etc/sysconfig/network/ifcfg-eth0 ein:
IPADDR_haendler='192.168.0.161'
NETMASK_haendler='255.255.255.0'
Danach muss der Netzwerkzugriff neu gestartet werden:
/etc/init.d/network restart
Ein PostgreSQL-Benutzer mit Namen haendler wurde (z.B. mit Hilfe von phpPgAdmin) angelegt.
Für diesen Benutzer wurden drei Datenbanken angelegt:
haendler_development (Zeichenkodierung UTF8)haendler_test (Zeichenkodierung UTF8)haendler_production (Zeichenkodierung UTF8)
Anlegen der Rails-Anwendung haendler
Zunächst werden im Rails-Webverzeichnis die Ordner und Dateien einer neuen Rails-Anwendung namens haendler erzeugt:
cd /web/rails
rails --database postgresql haendler
In der Konfigurations-Datei /web/rails/haendler/config/database.yml,
die den Zugriff auf das DB-System regelt, wird das Passwort für den Benutzer
haendler an drei Stellen eingetragen:
development:
adapter: postgresql
encoding: unicode
database: haendler_development
pool: 5
username: haendler
password: geHEIM!?
test:
adapter: postgresql
encoding: unicode
database: haendler_test
pool: 5
username: haendler
password: geHEIM!?
production:
adapter: postgresql
encoding: unicode
database: haendler_production
pool: 5
username: haendler
password: geHEIM!?
Mit Hilfe eines rake-Kommandos kann überprüft werden, ob die
Verbindung zur Datenbank hergestellt werden kann:
cd /web/rails/haendler
rake db:migrate
Wenn das rake-Kommando keinen Fehler ausgibt, ist alles in Ordnung.
Zugang zur Web-Anwendung haendler mit Hilfe von Apache
Unter der Annahme, dass Rails-Anwendungen im Verzeichnis /web/rails
angelegt werden, kann der virtuelle Server in der Apache-Konfigurationsdatei httpd.conf
eingetragen werden:
<VirtualHost 192.168.0.161:80>
ServerName haendler.kowa
DocumentRoot /web/rails/haendler/public
<Directory /web/rails/haendler/public>
AllowOverride All
Order allow,deny
Allow from all
</Directory>
CustomLog logs/haendler-access combined
ErrorLog logs/haendler-error
</VirtualHost>
Nach einem Neustart von Apache mit /etc/rc.d/apache restart oder, schneller,
kill -1 <Prozessnummer des Apache-Root-Prozesses> sollte man die Applikation
im Browser ansehen können:
http://haendler.kowa/
Konvention: Kalssennamen stehen im Singular und Datenbanktabellen-Namen im Plural
Für Ruby on Rails wurde die Konvention eingeführt, dass Klassennamen stets in Singular stehen und mit einem Großbuchstaben beginnen: Haendler,
Liefert, Ware. Die zugehörigen Tabellennamen sollen dagegen im Plural stehen und kleingeschrieben werden.
Die zweite Regel führt allerdings bei deutschen Tabellennamen sowie bei englischnamigen Beziehungstabellen zu unschönen Ergebnissen, wenn die Tabellen gemäß Konvention z.B. mittels
ruby script/generate erzeugt werden:
haendlers, lieferts, wares bzw. traders, supplies, items (hier
wäre supply besser).
Ich verwende normalerweise die Konvention, dass sowohl Klassen-, als auch Tabellennamen im Singular geschrieben werden sollten.
Dies könnte man erreichen, indem man folgende Zeile in die Datei /web/rails/haendler/config/initializers/pluralize_false.rb
mit folgenden Inhalt anlegt.
ActiveRecord::Base.pluralize_table_names = false
Eine zweite Möglichkeit ist, die Konvention zu beachten, aber Ausnahmen in die Datei /web/rails/haendler/config/initializers/inflections.rb einzufügen:
ActiveSupport::Inflector.inflections do |inflect|
inflect.irregular 'haendler', 'haendler'
inflect.irregular 'liefert', 'liefern'
inflect.irregular 'ware', 'waren'
end
Das es nun einmal Ruby-on-Rails-Konvention ist, Tabellennamen im Plural zu schreiben, benutze ich in diesem Beispiel die zweite Möglichkeit.
Anlegen des Models (d.h. der Datenbanktabellen)
Mit Hilfe des Ruby-Skriptes ruby script/generate model können nun die Dateien für die Klassen- und Tabellen-Definitionen angelegt werden. Man beachte, dass die Beziehungsklasse Liefert bzw. die Beziehungstabelle liefern explizit angelegt wird, da sie über eigene Attribute verfügt.
cd /web/rails/haendler/
ruby script/generate model haendler
ruby script/generate model ware
ruby script/generate model liefert
Ergebnis:
exists app/models/
exists test/unit/
exists test/fixtures/
create app/models/haendler.rb
create test/unit/haendler_test.rb
create test/fixtures/haendlers.yml
create db/migrate
create db/migrate/20081208135556_create_haendlers.rb
...
Nun werden die Attribute in die zugehörigen migrate-Dateien eingefügt.
vi /web/rails/haendler/db/migrate/*_create_haendler.rb
class CreateHaendler < ActiveRecord::Migration
def self.up
create_table :haendler do |t|
t.string :name, :null => false
t.string :adresse
t.timestamps
end
end
def self.down
drop_table :haendler
end
end
vi /web/rails/haendler/db/migrate/*_create_waren.rb
class CreateWaren < ActiveRecord::Migration
def self.up
create_table :waren do |t|
t.string :typ
t.string :bezeichnung
t.timestamps
end
end
def self.down
drop_table :waren
end
end
vi /web/rails/haendler/db/migrate/*_create_liefern.rb
class CreateLiefern < ActiveRecord::Migration
def self.up
create_table :liefern do |t|
# numeric(6,2) wird von Rails nicht direkt unterstützt
t.column :preis, 'numeric(6,2)'
t.integer :lieferzeit, :null => false
t.timestamps
end
end
def self.down
drop_table :liefern
end
end
