Forum: Italian Ruby user group L'ereditarieta' in rails.

Class Person.
Se poi volessi avere Employee, Manager, etc. una cosa da fare sarebbe
derivare queste classi da Person.
L'ereditarieta' STI, single table inheritation, indica di mettere un
campo type sulla tabella, in questo caso people, in modo da poter
distinguere l'employee dal manager, etc.
Questo va bene se tutte le classi hanno gli stessi attributi.
Se, ad esempio, employee estende person avra' oltre agli attributi di
person anche degli altri propri.
In questo caso si rende necessario riservare una tabella per employee
ed allora tantovale creare un modello a se stante di Employee senza
necessariamente derivarlo da Person.
Qualcosa mi sfugge?

Io personalmente sono d'accordo, puoi cavartela se c' un campo di
differenza o due, ma per il resto la STI  per le situazioni di effettiva
identit di struttura.

2012/5/4 Mauro <mrsanna1@gmail.com>

Non mi e` chiarissimo....
ma se mettessi due booleani? magari aggiungendo un paio di scope view.
Poi ti gestisci tramite le validazioni i campi obbligatori specifici.

es:
t.string name
t.string code
t.boolean impiegato
t.boolean manager
t.string manager_area

validates :manager_area, :presence => true, :if => :manager?

Ovviamente se le differenze sono molte e` inadatto.

Andrea

On May 4, 2012, at 12:41 PM, Mauro wrote:

> ed allora tantovale creare un modello a se stante di Employee senza
> necessariamente derivarlo da Person.
> Qualcosa mi sfugge?

Forse quello che vuoi e' una polimorfica piuttosto che sti, in quel caso 
hai nella classe base gli attributi comuni e delle tabelle/classi 
separate quando l'oggetto e' differente.

  ngw

--
[ 926381, 23200231779, 1299022, 1045307475 ].collect { |a| a.to_s( 36 ) 
}.join( " " )
Nicholas Wieland (ngw)
ngw@nofeed.org
http://nofeed.org

Ciao,
raramente mi sono trovato nei guai con l'STI, ma non nego che qualche 
volta  successo.
Quindi suggerisco anche io di pensare bene al design prima.
Nel caso che citi mi pare che si tratti di utenti di un sistema (anche 
solo potenziali), ed  una classica tentazione
per l'uso dell'STI, perch ti consente di avere tutti gli utenti del 
sistema in una tabella sola.

> In questo caso si rende necessario riservare una tabella per employee
> ed allora tantovale creare un modello a se stante di Employee senza

Questo non lo capisco, che vuoi dire?

Nel tuo caso avrai:

class Person
end

class Employee < Person
end

class Manager < Person
end

e la colonna type sar popolata rispettivamente con:

- nil
- Empolyee
- Manager

Se gli attributi e i metodi di employe e manager divergono troppo, 
spostali in modelli a parte, con o senza tabelle,
con una relazione has_one o con una banale composition e te la dovresti 
cavare bene.

2012/5/4 Fabrizio Regini <freegenie@gmail.com>:
>
>
> e la colonna type sar popolata rispettivamente con:
>
> - nil
> - Empolyee
> - Manager
>
> Se gli attributi e i metodi di employe e manager divergono troppo, spostali in 
modelli a parte, con o senza tabelle,
> con una relazione has_one o con una banale composition e te la dovresti cavare 
bene.

Intendevo questo quando ho scritto che tantovale creare dei modelli a 
parte.