🚀 go-pugleaf

On Tue, 01 Jan 2008 16:28:01 -0000, Maciej Piechotka  
<uzytkownik2@gmail.com> wrote:

> 1. W Ruby się da ale *ActiveRecord* tego *nie* *obsługuje* (przynajmniej
> tak piszą sami w wiki).

Myśle, że da się i w AR ale nie na wbudowanych makrach bo są zabyt  
prymitywne. Trzeba to zrobić na własnych metodach. Tu masz działający kod  
dla pierwszego przypadku. Użyłem tu Sequela (bo jest dużo lepszy od AR):

require 'rubygems'
require 'sequel_model'

DB = Sequel('mysql://root:@localhost/test')

class Parent < Sequel::Model(:parents)
   # Ta deklaracja jest opcjonalna
   # Używam jej aby stworzyć tabelę w bazie
   set_schema do
     primary_key :id
     varchar     :type, :null => false
     varchar     :pole_parent
     varchar     :pole1
     varchar     :pole2
   end
end

# Tworzymy tabelę, (jeśli istniała zostanie usunięta)
Parent.create_table!

# Opcjonalnie trochę przyblokuję możliwość
# zapisu do niewłaściwego pola
module DatabaseSecurity
   def forbidden(fields)
     forbidden_fields = fields & changed_columns
     unless forbidden_fields.empty?
       raise "#{self.class} has no access to #{forbidden_fields.join(',  
')}!"
     end
   end
end

class Parent < Sequel::Model(:parents)
   include DatabaseSecurity
   before_save do
     forbidden [:pole1, :pole2]
     self.type = self.class.to_s
   end
end

# Kolejne klasy nie mają swoich tabel,
# operują na tej jednej, odziedziczonej

class Child1 < Parent
   before_save do
     forbidden [:pole_parent, :pole2]
     self.type = self.class.to_s
   end
end

class Child2 < Parent
   before_save do
     forbidden [:pole_parent, :pole1]
     self.type = self.class.to_s
   end
end

# No to potestujmy:

Parent.create :pole_parent => 'parent value'
Child1.create :pole1 => 'child1 value'
Child2.create :pole2 => 'child2 value'
Parent.all.map{|row| p row.values}
# wyniki:
# {:type=>"Parent", :pole_parent=>"parent value", :pole1=>nil,  
:pole2=>nil, :id=>1}
# {:type=>"Child1", :pole_parent=>nil, :pole1=>"child1 value",  
:pole2=>nil, :id=>2}
# {:type=>"Child2", :pole_parent=>nil, :pole1=>nil, :pole2=>"child2  
value", :id=>3}


> Tzn. Zawsze da się pisać save/select/find przy
> użyciu SQL ale chyba nie o to chodzi w korzystaniu z AR.

Co ty powiadasz. Właśnie o to chodzi, że kontroler w ogóle nie powinien  
posługiwać się metodami specyficznymi dla danego ORM'a. Zgodnie z zasadą  
"cienkiego kontrolera i bogatego modelu" model powinien ukrywać swoją  
implementację tak, abym mógł bez żadnych zmian w kontrolerze wymienić go  
na inną implementację. Z tego wniosek, że jedyne metody modelu jakie są  
dostępne dla kontrolera to custom methods. I można je w Ruby tak owrapować  
z SQL czy bez że uzyskać te łamańce połączeniowe jakie podałeś. Różnica  
tylko taka, że w Active Record będę musiał użyć SQL'a. Zaś w wpadku  
Sequela tego nie muszę robić, bo jest wystarczająco elastyczny.

> 2. Nie zawsze zaczyna się od tabel - czasami tworzy się kod równolegle.

Dane biznesowe są ważniejsze od aplikacji. Zrozumiałem, że miałeś sytuację  
że jest dana baza i należy jakoś ją zamapować w Ruby.

Tworzenie struktur tabel za pomocą ORM'a nigdy nie będzie doskonałe i nie  
jest możliwe uniknąć SQL jeśli chcemy naprawdę mieć porządną i  
nietrywialną strukturę. Nawet Hibernate ci nic nie pomoże. Optymalizacja  
bazy wymaga użycia specificznych dla niej rozszerzeń SQL'a i już.

-- 
Jarosław Zabiełło
http://blog.zabiello.com