🚀 go-pugleaf

Marcin wrote:

> Witam,
> 
> Mam prośbę do ludzi, którzy programują w PHP i teraz jeszcze dodatkowo
> programują w Ruby korzystając z Rails.
> 
> Jestem zainteresowany RoR i chciałbym się dowiedzieć w czym tak na
> prawdę tkwi siła RoR?
> Chciałbym jednak przeczytać obiektywne wypowiedzi :)
> 
> Znam PHP dlatego prośba o odniesienie się do PHP, a nie np. do Javy.
> 

Troll?

Weź pierwszy z brzegu tutorial i sam się przekonaj.

-- 
.:: Piter // phlawski$gmail,com // gg: 4534287 ::.
Czas nie czeka na nikogo. Chyba, że tym kimś jest Chuck Norris.

Piotr 'piter' Hlawski pisze:
> Marcin wrote:
  > Weź pierwszy z brzegu tutorial i sam się przekonaj.
> 

Dokładnie. To musisz poczuć sam, nie ma co porównywać, przekonywać. Z 
tego mógłby być tylko flame war ;).

Marcin wrote:

> Jestem zainteresowany RoR i chciałbym się dowiedzieć w czym tak na
> prawdę tkwi siła RoR?

W tym, ze jest napisany w Ruby, jest calkiem niezle zaprojektowany, ma
swietny system wtyczek i wzglednie dobrze sie rozwija. Uogolniajac :)

-- 
# Pozdrawiam || piotr[.]solnica[at]gmail[.]com || jid : s0lnic@jabster.pl #
# s0lnic     || http://blog.solnic.eu          || gg  : 1439837           #

On Sat, 29 Dec 2007 21:26:26 +0100, Marcin wrote:

> Witam,
> 
> Mam prośbę do ludzi, którzy programują w PHP i teraz jeszcze dodatkowo
> programują w Ruby korzystając z Rails.
> 
> Jestem zainteresowany RoR i chciałbym się dowiedzieć w czym tak na
> prawdę tkwi siła RoR?
> Chciałbym jednak przeczytać obiektywne wypowiedzi :)
> 
> Znam PHP dlatego prośba o odniesienie się do PHP, a nie np. do Javy.

PHP to język a RoR to framework oparty na Ruby'im. Różnice i podobieństwa 
ruby i php: http://www.ruby-lang.org/en/documentation/ruby-from-other-
languages/to-ruby-from-php/

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

s0lnic pisze:
> Marcin wrote:
> 
>> Jestem zainteresowany RoR i chciałbym się dowiedzieć w czym tak na
>> prawdę tkwi siła RoR?
> 
> W tym, ze jest napisany w Ruby, jest calkiem niezle zaprojektowany, ma
> swietny system wtyczek i wzglednie dobrze sie rozwija. Uogolniajac :)

System wtyczek - brzmi całkiem obiecująco :) Dzięki za odpowiedź.

Popełniłem jednak mały błąd w temacie i nikt nie zwrócił na to uwagi :) 
Chodziło mi raczej o Ruby vs PHP. W PHP też są całkiem niezłe frameworki 
:) więc framework dla Ruby vs PHP nie bardzo się ma jedno do drugiego ;)

-- 
Pozdrawiam,
Marcin

Maciej Piechotka pisze:
> PHP to język a RoR to framework oparty na Ruby'im. 

O! No dokładnie. Popełniłem błąd w tytule postu.

> Różnice i podobieństwa ruby i php: http://www.ruby-lang.org/en/documentation/ruby-from-other-
> languages/to-ruby-from-php/

Dzięki za przydatny link!

-- 
Pozdrawiam,
Marcin

Radarek pisze:
> Piotr 'piter' Hlawski pisze:
>> Marcin wrote:
>  > Weź pierwszy z brzegu tutorial i sam się przekonaj.
>>
> 
> Dokładnie. To musisz poczuć sam, nie ma co porównywać, przekonywać. Z 
> tego mógłby być tylko flame war ;).

Do flame war bardzo mi daleko :) Unikam tego jak ognia. Za to sensownie 
podyskutować zawsze można. Słyszałem dużo dobrego o RoR więc głupotą by 
było nie zaznajomić się z tym wynalazkiem i nie zobaczywszy co to to 
potrafi przejść obojętnie obok tego :)

PS: że muszę poczuć sam to się samo przez się rozumie. Podobnie jak z 
seksem ;) Dużo by można mówić - trzeba samemu spróbować ;)

-- 
Pozdrawiam,
Marcin

On Sun, 30 Dec 2007 12:22:53 -0000, Maciej Piechotka  
<uzytkownik2@gmail.com> wrote:

> Różnice i podobieństwa
> ruby i php: http://www.ruby-lang.org/en/documentation/ruby-from-other-
> languages/to-ruby-from-php/

Tu jest to samo ale po polsku
http://www.ruby-lang.org/pl/dokumentacja/ruby-a-inne-jezyki-programowania/ruby-a-php/

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

On Sat, 29 Dec 2007 20:26:26 -0000, Marcin <marlej@gazeta.pl> wrote:

> Jestem zainteresowany RoR i chciałbym się dowiedzieć w czym tak na  
> prawdę tkwi siła RoR?

Tak najkrócej mówiąc, siłą RoR jest *piękno i prostota* tworzenia  
aplikacji webowych za pomocą znacznie lepiej zaprojektowanego języka niż  
PHP - Rubiego. Prosto, schludnie i wszystko na swoim miejscu. RoR prowadzi  
cię za rękę dzięki generatorom kodu. Automatycznie powiązuje nazwy  
kontrolerów z odpowiadającymi im szablonami. Pozwala komunikować się z  
bazą w sposób obiektowy, za pomocą Rubiego. Ma silne wsparcie dla AJAX'a i  
sporo wygodnych helperów, funkcji ułatwiających generowanie kodu HTML czy  
JavaScript. Do tego ma bardzo dobry (darmowy) edytor IDE - Netbeans 6  
(http://deadlock.netbeans.org/hudson/job/ruby/) pozwalający też na krokowe  
śledzenie kodu aplikacji   
(http://www.netbeans.org/kb/60/ruby/debugger-screencast.html). Do Rubiego  
i Railsów powstaje sporo książek, też po polsku (Helion). Poza tym RoR  
można odpalać na też JRuby i tym samym można w pełni korzystać z bogatych  
bibliotek Javy. Można by dużo pisać o RoR i Ruby i mógłbym tu wymienić  
tonę wad PHP, ale nie o to chodzi. Najlepiej spóbuj RoR i sam się  
przekonaj.

Zobacz też "Dlaczego Ruby on Rails jest wyjątkowy?"
http://blog.zabiello.com/articles/2006/05/14/dlaczego-ruby-on-rails-jest-wyj%C4%85tkowy

BTW, niedawno RoR doczekał się już ciekawej konkurencji w postaci Merb'a  
http://merbivore.com/. Też wykorzystuje język Ruby. Jest bardzo podobny do  
RoR ale szybszy i w wielu aspektach lepszy.

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

Cześć,

Jaroslaw Zabiello pisze:
> Tu jest to samo ale po polsku
> http://www.ruby-lang.org/pl/dokumentacja/ruby-a-inne-jezyki-programowania/ruby-a-php/ 

Dzięki za tłumaczenie :)

-- 
Pozdrawiam,
Marcin

Witam,

Jaroslaw Zabiello pisze:
> On Sat, 29 Dec 2007 20:26:26 -0000, Marcin <marlej@gazeta.pl> wrote:
> 
>> Jestem zainteresowany RoR i chciałbym się dowiedzieć w czym tak na 
>> prawdę tkwi siła RoR?
> 
> Tak najkrócej mówiąc, siłą RoR jest

Dziękuję za bardzo wyczerpującą odpowiedź :)

Tak przy okazji - faktycznie Ruby tak słabo obsługuje mapowanie między 
obiektami a relacyjnymi bazami danych (ORM) jak to gdzieś przeczytałem?
Jak to faktycznie jest? Zamierzam akurat dość mocno współpracować w 
relacyjnymi bazami danych przy pomocy moich aplikacji internetowych.

-- 
Pozdrawiam,
Marcin

On Sun, 30 Dec 2007 22:42:07 +0100, Marcin wrote:

> Witam,
> 
> Jaroslaw Zabiello pisze:
>> On Sat, 29 Dec 2007 20:26:26 -0000, Marcin <marlej@gazeta.pl> wrote:
>> 
>>> Jestem zainteresowany RoR i chciałbym się dowiedzieć w czym tak na
>>> prawdę tkwi siła RoR?
>> 
>> Tak najkrócej mówiąc, siłą RoR jest
> 
> Dziękuję za bardzo wyczerpującą odpowiedź :)
> 
> Tak przy okazji - faktycznie Ruby tak słabo obsługuje mapowanie między
> obiektami a relacyjnymi bazami danych (ORM) jak to gdzieś przeczytałem?
> Jak to faktycznie jest? Zamierzam akurat dość mocno współpracować w
> relacyjnymi bazami danych przy pomocy moich aplikacji internetowych.

To zależy co nazywasz 'słabo'. Ma pewne konwencje które mogą sprawić że 
klasa Post wygląda:

class Post < ActiveRecord::Base
end

Piszę z pamięci bo taki kod jest w railsach generowany.

Railsy (a właściwie ActiveRecord) z założenia pracują na ORM. A ruby jako 
taki tego nie obsługuje.

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

Marcin pisze:
> Tak przy okazji - faktycznie Ruby tak słabo obsługuje mapowanie między 
> obiektami a relacyjnymi bazami danych (ORM) jak to gdzieś przeczytałem?
> Jak to faktycznie jest? Zamierzam akurat dość mocno współpracować w 
> relacyjnymi bazami danych przy pomocy moich aplikacji internetowych.
> 

Na pewno nie gorzej niż PHP, więc nie musisz się niczego obawiać. 
ActiveRecord spełnia większość oczekiwań.

On Sun, 30 Dec 2007 21:42:07 -0000, Marcin <marlej@gazeta.pl> wrote:

> Tak przy okazji - faktycznie Ruby tak słabo obsługuje mapowanie między  
> obiektami a relacyjnymi bazami danych (ORM) jak to gdzieś przeczytałem?
> Jak to faktycznie jest? Zamierzam akurat dość mocno współpracować w  
> relacyjnymi bazami danych przy pomocy moich aplikacji internetowych.

Ruby, słabo? A co Ruby ma tu do rzeczy? To kwestia jakości i możliwości  
danej biblioteki realizującej mapowanie relacyjno obiektowe. Generalnie  
liczą się 3 biblioteki ORM: Active Record (wbudowana w Rails:  
http://ar.rubyonrails.org/), DataMapper (http://www.datamapper.org/) i  
Sequel (http://code.google.com/p/ruby-sequel/).

Moim zdaniem najlepsza jest ta trzecia, duże możliwości, dobra wydajność,  
jest odporna na wątki i pozwala na łatwe konstruowanie dużo bardziej  
skomplikowanych konstrukcji niż pierwsze dwie. Można ją też zintegrować z  
Railsami.
http://blog.zabiello.com/articles/2007/12/21/integracja-rails-z-sequelem.  
Ale na początek możesz zacząć z tym co jest standardowo wbudowane w Rails.  
Jeśli będziesz się trzymał reguły bogatego modelu-cienkiego kontrolera to  
potem łatwo można wymienić Active Record na DataMapper lub Sequel jeśli  
jest taka potrzeba. Vide http://ruby-rails.pl/rails-10-przykazan/ i   
http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model.

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

On Sun, 30 Dec 2007 22:19:39 -0000, Maciej Piechotka  
<uzytkownik2@gmail.com> wrote:

> To zależy co nazywasz 'słabo'.

Może koledze chodziło np. o to:
http://blog.zabiello.com/articles/2007/12/13/slabosci-active-record
?

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

Jaroslaw Zabiello pisze:
> Może koledze chodziło np. o to:
> http://blog.zabiello.com/articles/2007/12/13/slabosci-active-record

Tego akurat jeszcze nie czytałem (dzięki za linka) :) , a chodziło mi 
górę strony nr 10 z książki "Ruby on Rails - wprowadzenie" :
http://helion.pl/ksiazki/rubywp.htm

PS: co by jednak nie mówić/pisać przygoda z RoR zapowiada się bardzo 
obiecująco :)

-- 
Pozdrawiam,
Marcin

On Mon, 31 Dec 2007 00:41:17 +0100
Marcin <marlej@gazeta.pl> wrote:

> Tego akurat jeszcze nie czytałem (dzięki za linka) :) , a chodziło mi 
> górę strony nr 10 z książki "Ruby on Rails - wprowadzenie" :
> http://helion.pl/ksiazki/rubywp.htm

Skoro się powołujesz na książki, czytaj ze zrozumieniem :)

"Ruby on Rails - wprowadzenie"

"""Język Ruby na przykład dość słabo obsługuje mapowanie między
obiektami a relacyjnymi bazami danych dla schematów dziedziczenia
(ang. legacy schemas)."""

"""[2] Na przykład środowisko Hibernate języka Java obsługuje trzy
sposoby mapowania dziedziczenia, natomiast język Ruby obsługuje tylko
dziedziczenie oparte na dziedziczeniu. Hibernate obsługuje również
klucze złożone (ang. composite keys), a Ruby nie."""

Swoją drogą, bardzo dziwnie jest to napisane, ponieważ autor książki
porównuje ORM (konkretnie Hibernate) z.. językiem :)

-- 
      -^-  _        coś tam w tle sobie gra, np:
   _ /O)_\//        EXIT - FAR AWAY FROM HERE
  (_(|__(_(_) grf.  

On Mon, 31 Dec 2007 08:46:48 +0100, Roman Dobosz wrote:

> On Mon, 31 Dec 2007 00:41:17 +0100
> Marcin <marlej@gazeta.pl> wrote:
> 
>> Tego akurat jeszcze nie czytałem (dzięki za linka) :) , a chodziło mi
>> górę strony nr 10 z książki "Ruby on Rails - wprowadzenie" :
>> http://helion.pl/ksiazki/rubywp.htm
> 
> Skoro się powołujesz na książki, czytaj ze zrozumieniem :)
> 
> "Ruby on Rails - wprowadzenie"
> 
> """Język Ruby na przykład dość słabo obsługuje mapowanie między
> obiektami a relacyjnymi bazami danych dla schematów dziedziczenia (ang.
> legacy schemas)."""
> 
> """[2] Na przykład środowisko Hibernate języka Java obsługuje trzy
> sposoby mapowania dziedziczenia, natomiast język Ruby obsługuje tylko
> dziedziczenie oparte na dziedziczeniu. Hibernate obsługuje również
> klucze złożone (ang. composite keys), a Ruby nie."""
> 
> Swoją drogą, bardzo dziwnie jest to napisane, ponieważ autor książki
> porównuje ORM (konkretnie Hibernate) z.. językiem :)

I to z AR a istnieją conajmniej 2 konkurencyjne ORM'y (wykorzystywane 
przez merb) - i obsługują klucze złożone (przynajmniej jedno z nich).
Nie wiem jak z dziedziczeniem.

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

Maciej Piechotka wrote:

> I to z AR a istnieją conajmniej 2 konkurencyjne ORM'y (wykorzystywane
> przez merb) - i obsługują klucze złożone (przynajmniej jedno z nich).
> Nie wiem jak z dziedziczeniem.

Jezeli AR nie zostanie usprawniony / rozbudowany to raczej ludzie odejda od
niego, szkoda, ze ostatnie zmiany w RoR glownie skupily sie na mniej
istotnych sprawach i w AR bardzo malo sie zmienilo.

-- 
# Pozdrawiam || piotr[.]solnica[at]gmail[.]com || jid : s0lnic@jabster.pl #
# s0lnic     || http://blog.solnic.eu          || gg  : 1439837           #

On Mon, 31 Dec 2007 07:46:48 -0000, Roman Dobosz <gryf_esm-no@spam-o2.pl>  
wrote:

> """Język Ruby na przykład dość słabo obsługuje mapowanie między
> obiektami a relacyjnymi bazami danych dla schematów dziedziczenia
> (ang. legacy schemas)."""
>
> """[2] Na przykład środowisko Hibernate języka Java obsługuje trzy
> sposoby mapowania dziedziczenia, natomiast język Ruby obsługuje tylko
> dziedziczenie oparte na dziedziczeniu. Hibernate obsługuje również
> klucze złożone (ang. composite keys), a Ruby nie."""
>
> Swoją drogą, bardzo dziwnie jest to napisane, ponieważ autor książki
> porównuje ORM (konkretnie Hibernate) z.. językiem :)

Tak, autor książki plecie coś bez sensu. Poza tym, co prawda, Active  
Record nie obsługuje złożonych kluczy obcych sam z siebie, ale wystarczy  
dograć gem composite_primary_keys (http://compositekeys.rubyforge.org/)  
aby zaczął obsługiwać. Wystarczy jednak przełączyć się na JRuby i można  
używać nawet i Hibernate. Bezpośrednio, jak w Javie albo za pomocą  
prostszej składni ala' Active Record dzięki bibliotece ActiveHibernate  
(http://code.google.com/p/activehibernate/). Inna sprawa, że ta ostatnia  
to jeszcze młody projekt.

Problemów ze złożonymi kluczami obcymi nie mają DataMapper ani Sequel,  
alternatywne ORM'y dla Rubiego (można używać w Rails nawet obok Active  
Record). Oczywiście każdy z nich może używać dziedziczenia tak jak Active  
Record. Ale co do tych trzech sposobów dziedziczenia, to nie wiem co autor  
miał na myśli. Nie znam tu Hibernate. Wydaje mi się, że Java ma przecież  
jednen, jasno określony sposób dziedziczenia.

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

On Mon, 31 Dec 2007 14:12:29 +0000, Jaroslaw Zabiello wrote:

> Problemów ze złożonymi kluczami obcymi nie mają DataMapper ani Sequel,
> alternatywne ORM'y dla Rubiego (można używać w Rails nawet obok Active
> Record). Oczywiście każdy z nich może używać dziedziczenia tak jak
> Active Record. Ale co do tych trzech sposobów dziedziczenia, to nie wiem
> co autor miał na myśli. Nie znam tu Hibernate. Wydaje mi się, że Java ma
> przecież jednen, jasno określony sposób dziedziczenia.

Chodzi o czy takie klasy:

+--------+
| Parent |
+--------+
| pole1  |
+--------+
    ^
    \------------\
     |           |
+--------+  +--------+
| Child1 |  | Child2 |
+--------+  +--------+
| pole2  |  | pole3  |
+--------+  +--------+

Będzie odwzorowane przez:
- 1 tabele Parent z pole1, pole2, pole3 i pole oznaczające typ
- 3 tabele: Parent z pole1, Child1 z pole1 i pole2 oraz Child2 pole1 i 
pole3
- 3 tabele: Parent z pole1, Child1 z pole2 i parent_id oraz Child2 z pole3 
i parent_id

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

On Mon, 31 Dec 2007 18:02:08 -0000, Maciej Piechotka  
<uzytkownik2@gmail.com> wrote:

> Chodzi o czy takie klasy:
>
> +--------+
> | Parent |
> +--------+
> | pole1  |
> +--------+
>     ^
>     \------------\
>      |           |
> +--------+  +--------+
> | Child1 |  | Child2 |
> +--------+  +--------+
> | pole2  |  | pole3  |
> +--------+  +--------+
>
> Będzie odwzorowane przez:
> - 1 tabele Parent z pole1, pole2, pole3 i pole oznaczające typ
> - 3 tabele: Parent z pole1, Child1 z pole1 i pole2 oraz Child2 pole1 i
> pole3
> - 3 tabele: Parent z pole1, Child1 z pole2 i parent_id oraz Child2 z  
> pole3 i parent_id

Nie wiem czy dobrze cię rozumiem. Mogłbyś podać pełną strukturę tabel i to  
jakie chciałbyś mieć powiązania między klasami ORM? Chodzi mi o jakiś  
przykład wywołania. Np. czy w pkt 1 chodzi o to aby mozna bylo mieć coś  
takiego?

Parent.pole1 (pobrane z Parent.pole1)
Parent.pole2
Parent.pole3 (pobrane z Child2.pole3)

Te dwa kolejne nie rozumiem.

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

On Mon, 31 Dec 2007 18:51:15 +0000, Jaroslaw Zabiello wrote:

> On Mon, 31 Dec 2007 18:02:08 -0000, Maciej Piechotka
> <uzytkownik2@gmail.com> wrote:
> 
>> Chodzi o czy takie klasy:
>>
>> +--------+
>> | Parent |
>> +--------+
>> | pole1  |
>> +--------+
>>     ^
>>     \------------\
>>      |           |
>> +--------+  +--------+
>> | Child1 |  | Child2 |
>> +--------+  +--------+
>> | pole2  |  | pole3  |
>> +--------+  +--------+
>>
>> Będzie odwzorowane przez:
>> - 1 tabele Parent z pole1, pole2, pole3 i pole oznaczające typ - 3
>> tabele: Parent z pole1, Child1 z pole1 i pole2 oraz Child2 pole1 i
>> pole3
>> - 3 tabele: Parent z pole1, Child1 z pole2 i parent_id oraz Child2 z
>> pole3 i parent_id
> 
> Nie wiem czy dobrze cię rozumiem. Mogłbyś podać pełną strukturę tabel i
> to jakie chciałbyś mieć powiązania między klasami ORM? Chodzi mi o jakiś
> przykład wywołania. Np. czy w pkt 1 chodzi o to aby mozna bylo mieć coś
> takiego?
> 
> Parent.pole1 (pobrane z Parent.pole1) Parent.pole2
> Parent.pole3 (pobrane z Child2.pole3)
> 
> Te dwa kolejne nie rozumiem.

class Parent
  attr_accessor :pole_parent
end

class Child1 < Parent
  attr_accessor :pole1
end

class Child2 < Parent
  attr_accessor :pole2
end

Rozwiązanie nr1(W rails):

CREATE TABLE parents (
  id INTEGER PRIMARY KEY AUTO_INCREMENT,
  type STRING NOT NULL, /* 'Parent', 'Child1' albo 'Child2' */
  pole_parent STRING,
  pole1 STRING,
  pole2 STRING
);

Rozwiązanie nr2:

CREATE TABLE parents (
  id INTEGER PRIMARY KEY AUTO_INCREMENT,
  pole_parent STRING
);

CREATE TABLE childs1 (
  id INTEGER PRIMARY KEY AUTO_INCREMENT,
  pole_parent STRING,
  pole1 STRING
);

CREATE TABLE childs2 (
  id INTEGER PRIMARY KEY AUTO_INCREMENT,
  type STRING NOT NULL,
  pole_parent STRING,
  pole2 STRING
);

Rozwiązanie nr 3:

CREATE TABLE parents (
  id INTEGER PRIMARY KEY AUTO_INCREMENT,
  pole_parent STRING
);

CREATE TABLE childs1 (
  parent_id INTEGER PRIMARY KEY,
  pole1 STRING,
  CONSTRAINT childs1_parent_id FOREIGN KEY
);

CREATE TABLE childs2 (
  parent_id INTEGER PRIMARY KEY,
  pole2 STRING,
  CONSTRAINT childs2_parent_id FOREIGN KEY
);

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

On Mon, 31 Dec 2007 23:49:24 -0000, Maciej Piechotka  
<uzytkownik2@gmail.com> wrote:

> class Parent
>   attr_accessor :pole_parent
> end
>
> class Child1 < Parent
>   attr_accessor :pole1
> end
>
> class Child2 < Parent
>   attr_accessor :pole2
> end
>
> Rozwiązanie nr1(W rails):
>
> CREATE TABLE parents (
>   id INTEGER PRIMARY KEY AUTO_INCREMENT,
>   type STRING NOT NULL, /* 'Parent', 'Child1' albo 'Child2' */
>   pole_parent STRING,
>   pole1 STRING,
>   pole2 STRING
> );
>
> Rozwiązanie nr2:
>
> CREATE TABLE parents (
>   id INTEGER PRIMARY KEY AUTO_INCREMENT,
>   pole_parent STRING
> );
>
> CREATE TABLE childs1 (
>   id INTEGER PRIMARY KEY AUTO_INCREMENT,
>   pole_parent STRING,
>   pole1 STRING
> );
>
> CREATE TABLE childs2 (
>   id INTEGER PRIMARY KEY AUTO_INCREMENT,
>   type STRING NOT NULL,
>   pole_parent STRING,
>   pole2 STRING
> );
>
> Rozwiązanie nr 3:
>
> CREATE TABLE parents (
>   id INTEGER PRIMARY KEY AUTO_INCREMENT,
>   pole_parent STRING
> );
>
> CREATE TABLE childs1 (
>   parent_id INTEGER PRIMARY KEY,
>   pole1 STRING,
>   CONSTRAINT childs1_parent_id FOREIGN KEY
> );
>
> CREATE TABLE childs2 (
>   parent_id INTEGER PRIMARY KEY,
>   pole2 STRING,
>   CONSTRAINT childs2_parent_id FOREIGN KEY
> );

Nic z tego nadal nie rozumiem. Przecież to, co stanowi faktyczne dane, to  
tabele w bazie. Taka struktura bazy jest konkretna i stała i w mapowaniu  
ORM chodzi o to aby tą materialną strukturę przedstawić za pomocą jakiś  
abstrakcji językowych. Ty zaś podajesz różne definicje tabel o tej samej  
nazwie... To w końcu która kwerenda tworzy tabelę childs1? Przecież nie  
mogą dotyczyć tej samej tabeli bo mają inne kolumny i klucz główny. A  
jeśli dotyczą dwóch różnych tabel to dlaczego noszą tą samą nazwę?

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

On Tue, 01 Jan 2008 01:10:35 +0000, Jaroslaw Zabiello wrote:
> Nic z tego nadal nie rozumiem. Przecież to, co stanowi faktyczne dane,
> to tabele w bazie. Taka struktura bazy jest konkretna i stała i w
> mapowaniu ORM chodzi o to aby tą materialną strukturę przedstawić za
> pomocą jakiś abstrakcji językowych. Ty zaś podajesz różne definicje
> tabel o tej samej nazwie... To w końcu która kwerenda tworzy tabelę
> childs1? Przecież nie mogą dotyczyć tej samej tabeli bo mają inne
> kolumny i klucz główny. A jeśli dotyczą dwóch różnych tabel to dlaczego
> noszą tą samą nazwę?

To są 3 sposoby przedstawienia prostej *hierarhii* klas w bazie danych. 
Tzn. Jak masz taką hierarchię klas to możesz ją przedstawić na 3 sposoby. 
Z przyczyn oczywistych te rozwiązania się *wykluczają*.

Możesz zastosować *albo* rozwiązanie nr. 1 *albo* rozwiązanie nr. 2 *albo* 
rozwiązanie nr. 3.

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

On Tue, 01 Jan 2008 10:57:23 -0000, Maciej Piechotka  
<uzytkownik2@gmail.com> wrote:

> To są 3 sposoby przedstawienia prostej *hierarhii* klas w bazie danych.
> Tzn. Jak masz taką hierarchię klas to możesz ją przedstawić na 3 sposoby.
> Z przyczyn oczywistych te rozwiązania się *wykluczają*.

To jest jakieś odwrócenie myślenia do góry nogami: "Mam klasy i je mapuję  
na tabele". To raczej powinno być odwrotnie, "Mam tabele i mapuję je na  
klasy". Przecież to, co jest dane to tabele i one są podstawą do mapowania  
a nie klasy. One są wtórne. I nie widzę żadnego problemu aby w Ruby  
zamapować kolumny z wielu tabel do jednej klasy (bo o to chyba tu Ci w tym  
wszystkim chodziło).

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

On Tue, 01 Jan 2008 15:16:33 +0100, Jaroslaw Zabiello <abuse@tpnet.pl>  
wrote:
>
> To jest jakieś odwrócenie myślenia do góry nogami: "Mam klasy i je  
> mapuję na tabele". To raczej powinno być odwrotnie, "Mam tabele i mapuję  
> je na klasy". Przecież to, co jest dane to tabele i one są podstawą do  
> mapowania a nie klasy. One są wtórne.

moje odczucia sa dokladnie odwrotne. mam wrazenie, ze dla Ciebie SQL jest  
jezykiem pierwotnym, jezykiem wyrazania podstawowych idei, a Ruby - jakas  
nakladka na to, ulatwiajaca stworzenie aplikacji webowej.

dla mnie jest odwrotnie. projektuje i programuje w Ruby'm, a SQL jest dla  
mnie zlem koniecznym. staram sie minimializowac jego uzycie na korzysc  
Ruby'ego. dla mnie podejscie: jak wymyslona przeze mnie klase przelozyc na  
tabele jest wlasnie podejsciem oczywistym i najprostszym.

> I nie widzę żadnego problemu aby w Ruby zamapować kolumny z wielu tabel  
> do jednej klasy (bo o to chyba tu Ci w tym wszystkim chodziło).

IMHO nie chodzi o mapowanie, ale zaprojektowanie struktury tabel dla  
hierarchii klas. sa przynajmniej 4 podejscia, kazde ma swoje wady i  
zalety. wiecej np. tutaj:  
http://www.agiledata.org/essays/mappingObjects.html#MappingInheritance

NB ten artykul tez stosuje podejscie: jak stworzyc tabele dla klas.

pzdr
	szeryf
-- 
Przemysław ,,Szeryf'' Kowalczyk :: http://szeryf.wordpress.com/

On Tue, 01 Jan 2008 14:16:33 +0000, Jaroslaw Zabiello wrote:

> On Tue, 01 Jan 2008 10:57:23 -0000, Maciej Piechotka
> <uzytkownik2@gmail.com> wrote:
> 
>> To są 3 sposoby przedstawienia prostej *hierarhii* klas w bazie danych.
>> Tzn. Jak masz taką hierarchię klas to możesz ją przedstawić na 3
>> sposoby. Z przyczyn oczywistych te rozwiązania się *wykluczają*.
> 
> To jest jakieś odwrócenie myślenia do góry nogami: "Mam klasy i je
> mapuję na tabele". To raczej powinno być odwrotnie, "Mam tabele i mapuję
> je na klasy". Przecież to, co jest dane to tabele i one są podstawą do
> mapowania a nie klasy. One są wtórne. I nie widzę żadnego problemu aby w
> Ruby zamapować kolumny z wielu tabel do jednej klasy (bo o to chyba tu
> Ci w tym wszystkim chodziło).

1. W Ruby się da ale *ActiveRecord* tego *nie* *obsługuje* (przynajmniej 
tak piszą sami w wiki). Tzn. Zawsze da się pisać save/select/find przy 
użyciu SQL ale chyba nie o to chodzi w korzystaniu z AR.

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

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

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

On Tue, 01 Jan 2008 15:54:50 -0000, Przemysław Kowalczyk  
<someone@microsoft.com> wrote:

> moje odczucia sa dokladnie odwrotne. mam wrazenie, ze dla Ciebie SQL  
> jest jezykiem pierwotnym, jezykiem wyrazania podstawowych idei, a Ruby -  
> jakas nakladka na to, ulatwiajaca stworzenie aplikacji webowej.

Nie chodzi o idee. Powtórzę to, co już napisałem.

1. *Dane biznesowe są ważniejsze od aplikacji*.

2. Pomijając proste przypadki, *optymalizacja bazy wymaga użycia  
specificznych dla niej rozszerzeń SQL'a*

Pełną spójność idei i implementacji uzyskasz tylko podczas pracy z  
prawdziwą *obiektową bazą danych*. Tylko, że nie napisano jeszcze takiej  
dla Rubiego...

> dla mnie jest odwrotnie. projektuje i programuje w Ruby'm, a SQL jest  
> dla mnie zlem koniecznym. staram sie minimializowac jego uzycie na  
> korzysc Ruby'ego. dla mnie podejscie: jak wymyslona przeze mnie klase  
> przelozyc na tabele jest wlasnie podejsciem oczywistym i najprostszym.

Tylko dla trywialnych przypadków. Ale już choćby zmiana silnika MySQL z  
domyślnego InnoDB na inny, albo pododawanie różnych collations dla  
poszczególnych kolumn wymaga sięgnięcia do SQL'a. Nawet Hibernate ci nie  
pomoże aby zamaskować różnicę między tak różnymi bazami jak MySQL,  
POstgreSQL, MSSQL i Oracle.

W sumie nie o to chodzi aby uciekać od SQL jak diabeł od święconej wody,  
ale aby używać tego, co praktyczne. Jak się da to oczywiście lepiej  
obiektowo. Ale jak jest coś nietypowego i aby uzyskać to w sposób  
obiektowy trzeba się nagimnastykować, to po prostu lepiej i *prościej*  
użyć SQL'a. Zresztą to jest celem tego biednego Active Record: uprościć  
pracę z danymi a nie na siłę robić wszystko w Ruby.

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

On Tue, 01 Jan 2008 18:11:36 +0000, Jaroslaw Zabiello wrote:

> 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}
> 

Ten typ jest obsługiwany przez AR pozostałych dwóch nie (nie wiem jak w 
sequel).

> 
>> 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.
> 

1. Oczywiście mówie o SQL'u w modelu a nie w kontrolerach.

2. Można prosić dla 3 metody kod (1 tabela na klasę) w Sequelu? 

3. Cały czas twierdzę, że AR nie potrafi tego zrobić z pudełka. To że 
można to pisać przy użyciu SQL'u albo DataMapper/Sequelu to ja wiem ;)
Ale w zasadzie mogę napisać model nie posługując się żadnym AR/DM/S w 
czystym Ruby + SQL.

>> 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.
> 

Nie. Mamy pewien model dziedziczenia (np. Person, Client, Employee) i mamy 
taką strukturę zapisać w bazie danych.

> 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ż.

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

On Tue, 01 Jan 2008 19:45:20 -0000, Maciej Piechotka  
<uzytkownik2@gmail.com> wrote:

> Można prosić dla 3 metody kod (1 tabela na klasę) w Sequelu?

class Parent < Sequel::Model(:parents)
   set_schema do
     primary_key :id
     varchar :pole_parent
   end
end

class Child1 < Sequel::Model(:childs1)
   set_schema do
     primary_key :parent_id
     varchar :pole1
   end
   class << self
     def next_id
       self.select(:max[:parent_id].as(:last_id)).first.last_id.to_i + 1
     end
   end
   before_save do
     unless Parent.filter(:id => Child1.next_id).first
       raise 'Parent cannot assign more childs1 objects'
     end
   end
end

Parent.create_table!
Child1.create_table!

Parent.create :pole_parent => 'Alojzy'
Child1.create :pole1 => 'Jas'
Parent.all.map{|row| p row.values}
Child1.all.map{|row| p row.values}
# => {:pole_parent=>"Alojzy", :id=>1}
# => {:pole1=>"Jas", :parent_id=>1}

Child1.create :pole1 => 'Malgosia'
# => Parent cannot assign more childs1 objects


>> Zrozumiałem, że miałeś sytuację że jest dana baza i należy jakośją  
>> zamapować w Ruby.
>
> Nie. Mamy pewien model dziedziczenia (np. Person, Client, Employee) i  
> mamy taką strukturę zapisać w bazie danych.

To jest bez sensu. Tzn. ma sens tylko w trywialnych przypadkach. I tylko  
tyle potrafią migracje AR. Każdy nietrywialny przykład wymaga dodania  
dodatkowego kodu poza samym attr_accessor. Przecież z podanego wcześniej  
przez ciebie modelu dziedziczenia kompletnie NIC nie wynika. Podałeś  
przecież:

class Parent
   attr_accessor :pole_parent
end

class Child1 < Parent
   attr_accessor :pole1
end

class Child2 < Parent
   attr_accessor :pole2
end

a w tabelach jakimś cudem wyskoczyły ci dodatkowe, inne pola. To nie jest  
pełny opis klas.

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

On Tue, 01 Jan 2008 19:45:20 -0000, Maciej Piechotka  
<uzytkownik2@gmail.com> wrote:

> 3. Cały czas twierdzę, że AR nie potrafi tego zrobić z pudełka.

Aby nie było, że tylko Sequel to potrafi. Masz tu implementację przykładu  
3 w Active Record. Pomijam tylko migracje tworzące tabelki.

require 'rubygems'
require 'active_record'

ActiveRecord::Base.establish_connection({
   :adapter => 'mysql',
   :database => 'test',
   :username => 'root',
   :password => ''
})

class Parent < ActiveRecord::Base
end

class Child1 < ActiveRecord::Base
   self.table_name = 'childs1'
   self.primary_key = 'parent_id'
   class << self
     def next_id
       maximum(:parent_id).to_i + 1
     end
   end
   before_save do
     begin
       Parent.find(Child1.next_id)
     rescue ActiveRecord::RecordNotFound
       raise 'Parent cannot assign more childs1 objects'
     end
   end
end

Parent.create :pole_parent => 'Alojzy'
Parent.find :all
# [#<Parent id: 6, pole_parent: "Alojzy">]
Child1.create :pole1 => 'Jas'
Child1.find :all
[#<Child1 parent_id: 1, pole1: "Jas">]

Child1.create :pole1 => 'Malgosia'
# => Parent cannot assign more childs1 objects

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

On Tue, 01 Jan 2008 23:14:53 -0000, Jaroslaw Zabiello <abuse@tpnet.pl>  
wrote:

> class Child1 < Sequel::Model(:childs1)
>    set_schema do
>      primary_key :parent_id
>      varchar :pole1
>    end
>    class << self
>      def next_id
>        self.select(:max[:parent_id].as(:last_id)).first.last_id.to_i + 1
>      end
>    end
>    before_save do
>      unless Parent.filter(:id => Child1.next_id).first
>        raise 'Parent cannot assign more childs1 objects'
>      end
>    end
> end

To samo, ale krócej:

class Child1 < Sequel::Model(:childs1)
   set_schema do
     primary_key :parent_id
     varchar :pole1
   end
   before_save do
     unless Parent[Child1.max(:parent_id).to_i + 1]
       raise 'Parent cannot assign more childs1 objects'
     end
   end
end

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

On Wed, 02 Jan 2008 03:53:39 +0000, Jaroslaw Zabiello wrote:

> On Tue, 01 Jan 2008 23:14:53 -0000, Jaroslaw Zabiello <abuse@tpnet.pl>
> wrote:
> 
>> class Child1 < Sequel::Model(:childs1)
>>    set_schema do
>>      primary_key :parent_id
>>      varchar :pole1
>>    end
>>    class << self
>>      def next_id
>>        self.select(:max[:parent_id].as(:last_id)).first.last_id.to_i +
>>        1
>>      end
>>    end
>>    before_save do
>>      unless Parent.filter(:id => Child1.next_id).first
>>        raise 'Parent cannot assign more childs1 objects'
>>      end
>>    end
>> end
> 
> To samo, ale krócej:
> 
> class Child1 < Sequel::Model(:childs1)
>    set_schema do
>      primary_key :parent_id
>      varchar :pole1
>    end
>    before_save do
>      unless Parent[Child1.max(:parent_id).to_i + 1]
>        raise 'Parent cannot assign more childs1 objects'
>      end
>    end
> end

Ale Child1 nie jest pochodną klasy Parent. W ruby oczywiście nie stanowi 
to dużego problemu, ale w pewnych przypadkach może. 

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

On Wed, 02 Jan 2008 08:33:31 -0000, Maciej Piechotka  
<uzytkownik2@gmail.com> wrote:

>> class Child1 < Sequel::Model(:childs1)
>>    set_schema do
>>      primary_key :parent_id
>>      varchar :pole1
>>    end
>>    before_save do
>>      unless Parent[Child1.max(:parent_id).to_i + 1]
>>        raise 'Parent cannot assign more childs1 objects'
>>      end
>>    end
>> end
>
> Ale Child1 nie jest pochodną klasy Parent.

Proszę bardzo. Oto wersja w której jest pochodną klasy Parent:

class Child1 < Parent
   set_dataset DB[:childs1]
   set_schema do
     primary_key :parent_id
     varchar :pole1
   end
   before_save do
     unless Parent[Child1.max(:parent_id).to_i + 1]
       raise 'Parent cannot assign more childs1 objects'
     end
   end
end

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

> 
> Proszę bardzo. Oto wersja w której jest pochodną klasy Parent:
> 
> class Child1 < Parent
>    set_dataset DB[:childs1]
>    set_schema do
>      primary_key :parent_id
>      varchar :pole1
>    end
>    before_save do
>      unless Parent[Child1.max(:parent_id).to_i + 1]
>        raise 'Parent cannot assign more childs1 objects'
>      end
>    end
> end

Dziękuję. Jak rozumiem find rozróżniający czy to Parent czy dziecko to 
tylko kwestia kilku linijek? (Zaczynam nabierać ochoty na migracje na 
sequel - tak znam http://blog.zabiello.com/articles/2007/12/21/integracja-
rails-z-sequelem). 

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

On Wed, 02 Jan 2008 11:24:23 -0000, Maciej Piechotka  
<uzytkownik2@gmail.com> wrote:

> Jak rozumiem find rozróżniający czy to Parent czy dziecko to
> tylko kwestia kilku linijek?

Używasz trochę za duże skróty myślowe. Nie jestem pewien co masz na myśli  
z tym rozróżnianiem.

-- 
Jarosław Zabiełło
http://blog.zabiello.com
irc://irc.eu.freenode.net/rubyonrails.pl

On Wed, 02 Jan 2008 13:08:09 +0000, Jaroslaw Zabiello wrote:

> On Wed, 02 Jan 2008 11:24:23 -0000, Maciej Piechotka
> <uzytkownik2@gmail.com> wrote:
> 
>> Jak rozumiem find rozróżniający czy to Parent czy dziecko to tylko
>> kwestia kilku linijek?
> 
> Używasz trochę za duże skróty myślowe. Nie jestem pewien co masz na
> myśli z tym rozróżnianiem.

parents:
+----+--------------+
| id | parent_value |
+----+--------------+
| 1  | To rodzic    |
| 2  | To dziecko   |
+----+--------------+
children:
+-----------+--------------+
| parent_id | child_value  |
+-----------+--------------+
| 2         | To dziecko   |
+-----------+--------------+

Parent.find(2) #=> {:id => 2, :parent_value => 'To dziecko', :child_value 
=> 'To dziecko'}

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

On Wed, 02 Jan 2008 20:01:35 -0000, Maciej Piechotka  
<uzytkownik2@gmail.com> wrote:

> On Wed, 02 Jan 2008 13:08:09 +0000, Jaroslaw Zabiello wrote:
>
>> On Wed, 02 Jan 2008 11:24:23 -0000, Maciej Piechotka
>> <uzytkownik2@gmail.com> wrote:
>>
>>> Jak rozumiem find rozróżniający czy to Parent czy dziecko to tylko
>>> kwestia kilku linijek?
>>
>> Używasz trochę za duże skróty myślowe. Nie jestem pewien co masz na
>> myśli z tym rozróżnianiem.
>
> parents:
> +----+--------------+
> | id | parent_value |
> +----+--------------+
> | 1  | To rodzic    |
> | 2  | To dziecko   |
> +----+--------------+
> children:
> +-----------+--------------+
> | parent_id | child_value  |
> +-----------+--------------+
> | 2         | To dziecko   |
> +-----------+--------------+
>
> Parent.find(2) #=> {:id => 2, :parent_value => 'To dziecko', :child_value
> => 'To dziecko'}

To jest trywialne tak samo w AR jak i Sequelu. Do klasu Parent dodajesz  
metodę child_value która wyciąga odpowiednie pole. W Ruby nie ma  
publicznych atrybutów klasy. Wszystkie zawsze są prywatne i jedynym  
dostępem do nich są metody (akcesory). A że nie muszą posiadać nawiasów,  
wygląda to tak jak w innych językach odczyt atrybutu klasy.

Dla Sequela byłoby to:

class Parent < Sequel::Model(:parents)
   #...
   def child_value
     Child.select(:parent_id => pk).first.child_value
   end

Odpowiednikiem Parent.find(2) będzie tu po prostu Parent[2]. Jak nie będzi  
rekordu, Sequel zwróci nil (AR zwraca dla takiej konstrukcji wyjątek).

-- 
Jarosław Zabiełło
http://blog.zabiello.com
irc://irc.eu.freenode.net/rubyonrails.pl

> Popełniłem jednak mały błąd w temacie i nikt nie zwrócił na to uwagi :) 
> Chodziło mi raczej o Ruby vs PHP. W PHP też są całkiem niezłe frameworki 
> :) więc framework dla Ruby vs PHP nie bardzo się ma jedno do drugiego ;)
> 

IMHO:

Ruby ma składnię, dzięki której kod jest duuuużo czytelniejszy niż w PHP.

Jest bardziej konsekwentny (nie ma tego co w PHP, gdzie niejednokrotnie 
jest np. różna kolejność podawania tych samych parametrów w funkcjach z 
jednej grupy).

m.

On Wed, 20 Feb 2008 09:03:07 -0000, edek <akjdjkdaiu@amazon.com> wrote:

>> Popełniłem jednak mały błąd w temacie i nikt nie zwrócił na to uwagi :)  
>> Chodziło mi raczej o Ruby vs PHP. W PHP też są całkiem niezłe  
>> frameworki :) więc framework dla Ruby vs PHP nie bardzo się ma jedno do  
>> drugiego ;)
>>
> Ruby ma składnię, dzięki której kod jest duuuużo czytelniejszy niż w PHP.
>
> Jest bardziej konsekwentny (nie ma tego co w PHP, gdzie niejednokrotnie  
> jest np. różna kolejność podawania tych samych parametrów w funkcjach z  
> jednej grupy).

Tak, PHO jest chaotyczny i niekonsekwetny (te ich nieśmiertelne prefiksy  
do metod...) Ruby jest dużo lepiej zaprojektowany od PHP. Różnic na  
niekorzyść PHP można by tak wymieniać bez końca.

-- 
Jarosław Zabiełło
http://blog.zabiello.com
irc://irc.eu.freenode.net/ruby.pl