🚀 go-pugleaf

On Sat, 24 Jun 2006 12:23:46 +0200, Przemek Wiśniewski wrote:

> Tak, ale ja chce informacje modelu wykorzystywac nie tylko do 
> generowania schematu bazy.

Celem ORM nigdy nie było generowanie schematu bazy.

>> Najpiekniej jednak tego typu kod wygląda w Railsach, np.:
>> 
>> class Author < ActiveRecord::Base
>>   has_many :articles
>>   validates_length_of :name, :maximum => 50
>>   validates_uniqueness_of :name,
>>                           :on => :create,
>>                           :message => "is already being used"
>>   validates_length_of :password, :in => 6..20
>>   validates_length_of :address, :minimum => 10,
>>                                 :message => "seems too short"
>> end
>> 
>> Na dodatek te istniejące już ORM robią to lepiej niż w twym przykładzie.
>> Np. robią to krócej, mają dobrane dobre wartości domyślne (np. nie trzeba w
>> modelu definiować pola primary key, nazwy tabel są automatycznie wiązane z
>> nazwą modelu, nazwy kluczy obcych też są automatycznie rozpoznawane, o ile
>> trzymasz się konwencji nazw dla pól)
> 
> Zaznaczam, ze bardzo nie lubie agile, extreme programming i innych 
> takich glupot wiec wszelka automagia nie robi na mnie pozytywnego 
> wrazenia.

Głupot? :-D Jaka znowu automagia? To jest własnie siła języka domenowego
czym się tak zachwycałeś. To nie żadna magia, to tylko Ruby. :)

A jak chcesz bardziej explicite, to popatrz na ORM Django , SQLObject czy
SQLAlchemy. 

> Widze, ze reguly walidacji sa przyklejone do modelu. A co jesli:
> 
> (1) Jeden model wykorzystuje w wielu formularzach i potrzebuje roznych 
> regul walidacji?

Każdy model ORM odpowiada standardowo jednej tabeli. Możesz na tej
podstawie tworzyć modele pochodne (na drodze dziedziczenia) i możesz
wzbogacać modele pochodne o metody, walidacje których pierwotny nie
posiada. Django do formularzy stosuje świetną technikę Manipulatorów.
Mapuje formularz na model, bardzo to ładnie wygląda w szablonach. Rails też
to może, ale trzeba dograć plugin ActiveForm (RadRails to dogra
automatycznie)

> (2) Co jesli model danych dla formularza wcale nie bedzie przechowywany 
> w bazie danych, bedzie tymczasowy?

Model formularza nie musi w ogóle mieć żadnych związków z bazą. W Django to
jest proste. Budujesz klasę przeciążającą klasę forms, która zajmuje się
formularzami.

from django import forms
class  MyFormManipulator(forms.Manipulator):
  def __init__(self):
        self.fields = (
            form.SelectField(field_name='name',is_required=True),
            )

> nie mialem na mysli zmiany w tworzanej ta technika aplikacji ale 
> zmiany w jezyku w ktorym tworzymy ta aplikacje. 

Tzn. chcesz odwrotnie? Zmieniasz w bazie i generujesz odpowiednie klasy?
Żaden problem: django_project/manage.py inspectdb > models.py. To samo dla
Railsów: rake db:schema (powstanie plik schema.rb z definicjami wszystkich
tabel)

> Jesli cos zle pomyslimy na poczatku (tak jak wyzej pisalem o walidacji)
> to zmiany moga byc kosztowne.

Pewne fundamenty lepiej mieć dobrze poukładane. Tego nie przeskoczysz.

> Opisuje pewna koncepcje - generowanie kodu z pewnego opisu. Chodzi mi 
> wlasnie o to, zeby poslugiwac sie tym opisem, a nie recznie laczyc rozne 
> dziwne biblioteki w calosc.

Opisem czego? Celem ORM nie jest zastępowanie SQL'a. Celem jest modelowanie
danych biznesowych. Wiadomo, że sam SQL jest za cienki aby dobrze opisać
model danych. ORM pozwala na dokładniejsze opisanie modelu biznesoweg.
Mapowanie tabel na klasę i pól tabeli na atrybuty to dopiero początek.
Możesz tworzyć z tego klasy potomne wzbogacone o dodatkowe mechanizmy.
ActiveRecord (ORM jaki używają Railsy) potrafi np. automatycznie, kaskadowo
wykonywać operacje na tabelach powiązanych nawet jak używasz bazy która w
ogóle nie obsługuje kluczy obcych (np. mysql3).

> Po drugie, skupiles sie tylko na tych nieszczesnych danych, a mi 
> chodzilo o calosc.  Nie widzisz korzysci z tego, ze mozna miec kompletna 
> aplikacje opisana w jednym jezyku? 

Ależ widzę. Jak używam Pythona, to używam ORM Pythona. Jak piszę w Ruby to
wolę ActiveRecord, bo jest w Ruby. Jak bym musiał męczyć się z PHP to
wybrałbym Propela.

> (2) Mozliwosc sprawdzenia poprawnosci calej aplikacji - mozemy sobie 
> sprawdzac czy na przyklad nigdzie nie odwolujemy sie do nieistniejacych 
> pol. 

Nie ma takiej potrzeby. Jeśli chodzi i walidację, to od tego są unittesty.
A Rails to w ogóle automatycznie tworzy pliki z testami jednostkowymi i
funkcjonalnymi do każdego generowanego modelu/kontrolera. 

> W moim zamysle taki generator pracuje jak kompilator jezyka bardzo 
> statycznie i silnie typowanego, jak na przyklad ghc (haskell).

Poza tym Python i Ruby sa na tyle dobre, że wyciągną z bazy potrzebne
definicje i zbudują sobie dynamiczne metody, który nazwy są określone nazwą
pól. To jest niemożliwe dla języków statycznych. Django jak i Rails
umożliwia także interaktywne bawienie się całym środowiskiem. Spróbuj to
zrobić w jęz. statycznym. :) Budowanie dynamicznego ORM na bazie języka
statycznego jest chore i niepotrzebne. Skończysz ostatecznie na statycznych
plikach XML, mówię ci. 
 
> Ja wcale nie chce bezposrednio uzywac gotowych bibliotek do ORMu, bo 
> moze sie okazac, ze nie potrzebuje ich tak bardzo, albo, ze nie 
> pokrywaja wszystkich moich potrzeb.

Lepiej się jednak z nimi *zapoznaj*, bo może się okazać, że niepotrzebnie
się męczysz aby zaimplementować coś, co już dawno napisano. Wpierw sprawdź
i jeśli stwierdzisz, że nie można czegoś osiągnąć w tamtych bibliotekach,
wtedy dopiero pomyśl o jakiejś własnej implementacji. Ale jak znam życie,
to jak się zapoznasz z tymi ORM, to stwierdzisz, że nie ma sensu pisać tego
od nowa.

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