Problemas con Single Table Inheritance

Juan_JosSSSS_Vidal · February 6, 2007, 10:17am

Hola a todos,

Trabajando con STI (Single Table Inheritance) me he encontrado con
alguna cosa que otra bastante sorprendente.

Suponiendo la siguiente jerarquÃa:

class Persona < ActiveRecord:Base
end

class Empleado < Persona
end

class Tecnico < Empleado
end

class Auxiliar < Empleado
end

A) Persona.find(:all)

Si hacemos un Persona.find(:all) veremos a todas las personas, es decir,
Todos los Empleados y todos los TÃ©cnicos.

B) Tecnico.find(:all)

Si hacemos un Tecnico.find(:all) veremos solo a las personas del tipo
Tecnico.

C) Auxiliar.find(:all)

Si hacemos un Auxiliar.find(:all) veremos solo a las personas del tipo
Auxiliar.

D) Empleado.find(:all)

Si hacemos un Empleado.find(:all) veremos a las personas del tipo
Empleado, pero Â¿por quÃ© NO vemos las personas del tipo Tecnico y del
tipo Auxiliar?

Esto deberÃa funcionar.

SoluciÃ³n FEA

He encontrado una forma para hacer que funcione, pero me parece
demasiado “mÃ¡gica” como para utilizarla con convencimiento:

Fallo

Si en el controlador de Empleado, en la acciÃ³n ‘list’ pongo:

def list
@empleados = Empleado.find(:all)
end

No verÃ© a los Tecnicos, ni a los Auxiliares en la vista. SÃ³lo veremos a
las personas del tipo Empleado.

OK

Si en el controlador de Empleado, en la acciÃ³n ‘list’ pongo:

def list
@tecnicos = Tecnico.find(:all)
@auxiliares = Auxiliar.find(:all)
@empleados = Empleado.find(:all)
end

De este modo cuando pongo esto, sÃ que verÃ© en la vista a las personas
del tipo Tecnico y del tipo Auxiliar, y ademÃ¡s… Â¡sÃ³lo recorriendo el
array @empleados!

DUDA

Tras leer mil sitios en la web, no he encontrado una soluciÃ³n al
problema (si es un problema)

Â¿SabÃ©is de algÃºn sitio que explique porquÃ© esto es asÃ??? Â¿lo sabÃ©is
vosotros?
Â¿Es un bug de rails??
Â¿Existe alguna soluciÃ³n “mÃ¡s limpia”?? (asÃ me parece demasiado “feo”)

Gracias por adelantado.
Un saludo!

–
Juan JosÃ© Vidal [email protected]
ATICA - Universidad de Murcia

Juan_JosSSSS_Vidal · February 6, 2007, 2:11pm

On 2/6/07, Juan José Vidal [email protected] wrote:

A) Persona.find(:all)

tipo Auxiliar?

OK
del tipo Tecnico y del tipo Auxiliar, y además… ¡sólo recorriendo el
¿Es un bug de rails??
¿Existe alguna solución “más limpia”?? (así me parece demasiado “feo”)

Hablo de cabeza, puedo meter la pata.
Para la STI creo que Rails incluye una columna “type” en la tabla que
guarda de que tipo de clase se trata (en tu caso Empleado, Tecnico,
Auxiliar). En las búsquedas el find de cada una de las clases
derivadas incluye una condición en plan “type = ‘Empleado’”, “type =
‘Tecnico’”, … mientras que para la clase padre la búsqueda no tiene
condiciones.

Por eso la busqueda por personas te funciona como esperas, pero la de
empleados no.

¿Bug? En cierto modo, digamos que Rails solo soporta particiones de un
solo nivel, no de dos como pretentes.

¿Una solución más limpia? Quizá redefinir el find de Empleado para que
las condiciones incluyan a los Tecnicos y a los auxiliares, pero hay
que hacerlo a mano y cada vez que incluyas una nueva subclase
tendrásque modificar el método.

Juan_JosSSSS_Vidal · February 6, 2007, 2:24pm

On mar, 2007-02-06 at 14:10 +0100, Daniel R. TroitiÃ±o wrote:

end

Empleado, pero Â¿por quÃ© NO vemos las personas del tipo Tecnico y del
Fallo

De este modo cuando pongo esto, sÃ que verÃ© en la vista a las personas
vosotros?
condiciones.
Migration ejemplo de Personas
====================================

create_table :personas do |t|
t.column :nombre, :string
t.column :identificador, :string <— para Empleado
t.column :carrera, :string <---------- para TÃ©cnico
t.column :estudios, :string <--------- para Auxiliar
t.column :type, :string
end

En la columna ‘type’ es dÃ³nde se guardan cada una de las clase.

Si insertamos datos en esta tabla (con diferentes vistas para Empleado,
Tecnico y Auxiliar), en la base de datos veremos en la columna ‘type’
los nombres de las clases pertinentes: Empleado, Tecnico y Auxiliar.

No existe a nivel de base de datos ninguna relaciÃ³n entre Empleado y
TÃ©cnico Ã³ Empleado y Auxiliar.

Esto estÃ¡ claro.

Por eso la busqueda por personas te funciona como esperas, pero la de
empleados no.

Â¿Bug? En cierto modo, digamos que Rails solo soporta particiones de un
solo nivel, no de dos como pretentes.

Â¿Seguro? Lo digo porque he visto en muchos blogs como definen una
relaciÃ³n del tipo que digo, mÃ¡s no dicen nada de que les falle ni nada.
De hecho, en el ‘Agile Development with Rails’ sale un ejemplo… al
menos el diagrama de clases sale dibujado al estilo Martin F…

Como por ejemplo (Babboon < OldWorldMonkey < Primate):
http://rails.raaum.org/database-conventions.html#sti

Â¿Una soluciÃ³n mÃ¡s limpia? QuizÃ¡ redefinir el find de Empleado para que
las condiciones incluyan a los Tecnicos y a los auxiliares, pero hay
que hacerlo a mano y cada vez que incluyas una nueva subclase tendrÃ¡s
que modificar el mÃ©todo.

Eso no vale como soluciÃ³n. SerÃa muy engorrosa… ademÃ¡s siempre estÃ¡ la
soluciÃ³n que he puesto en el primer correo.

Lo que mÃ¡s me sigue extraÃ±ando es este hecho (no termino de entenderlo):

del tipo Tecnico y del tipo Auxiliar, y ademÃ¡s… Â¡sÃ³lo recorriendo el
array @empleados!

Un saludo, y muchas gracias!

Juan_JosSSSS_Vidal · February 6, 2007, 4:03pm

On mar, 2007-02-06 at 15:21 +0100, javier ramirez wrote:

Efectivamente, a nivel de base de datos no hay relaciÃ³n, pero ahÃ es
donde entra “la magia” de AR. Si miras el log de una query que tenga STI
verÃ¡s que en el type le mete un “OR” por cada una de las ramificaciones
que se va encontrando desde la clase en la que buscas hacia sus
subclases. AquÃ la limitaciÃ³n es que el nombre tiene que ser Ãºnico en
cualquiera de los niveles porque si no vamos a tener conflictos… pero
es una soluciÃ³n lo suficientemente buena.

Â¿Seguro? Lo digo porque he visto en muchos blogs como definen una
relaciÃ³n del tipo que digo, mÃ¡s no dicen nada de que les falle ni nada.

Efectivamente, en el log sale:

Caso A)

Si en el controlador ponemos esto:

def list
@empleados = Empleado.find(:all)
end

En el log sale esto:

Empleado Load (0.001016) SELECT * FROM personas WHERE
( (personas.type = ‘Empleado’ ) )

Caso B)

Si en el controlador ponemos esto:

def list
@tecnicos = Tecnico.find(:all)
@auxiliares = Auxiliar.find(:all)
@empleados = Empleado.find(:all)
end

La salida del log es:

Empleado Load (0.000882) SELECT * FROM personas WHERE
( (personas.type = ‘Empleado’ OR personas.type = ‘Tecnico’ OR
personas.type = ‘Auxiliar’ ) )

En este caso perfecto.

Y tienes razÃ³n… tal cuÃ¡l lo planteas en tu mail original deberÃa
funcionar. Si no es asÃ se me ocurre que pueda ser por una mala
definiciÃ³n de las tablas (Â¿tienen todas la columna type?) o porque estÃ©s
sobreescribiendo el campo type a mano… o si no sÃ³lo se me ocurre algÃºn
tema de versiones.

SÃ³lo hay una tabla definida (adjunto esquema de ejemplo), por principios
de STI:

create_table :personas do |t|
  t.column :nombre, :string
  t.column :apellidos, :string
  t.column :nif, :string
  t.column :telefono, :string
  t.column :telefono_movil, :string
  t.column :fax, :string
  t.column :email, :string
  t.column :observaciones, :text
  t.column :type, :string
end

Simplemente juego en las vistas con estos datos, poniÃ©ndole unos sÃ y
otros no a las diferentes clases Tecnico, Auxiliar.

Si miras en tu base de datos, Â¿realmente todas las filas insertadas en
personas tienen el type bien puesto?

SÃ, eso es lo raro.

En la base de datos sale:

Nombre | Apellidos | Ã©tc… | type
Pedro PÃ©rez … Tecnico
Antonio GarcÃa … Auxiliar
… … … …

Un saludo!

[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es
–

Juan JosÃ© Vidal AgustÃn [email protected]
Universidad de Murcia
ÃTICA - Ãrea de TecnologÃas de la InformaciÃ³n y las Comunicaciones
Aplicadas
Proyecto SOFTLA - Software Libre y Abierto Universidad de Murcia
Edificio Ãtica, Campus Univ. de Espinardo
E-30100 Murcia (SPAIN)

Tlf.: +34 968 39 8741

Juan_JosSSSS_Vidal · February 6, 2007, 5:06pm

@tecnicos = Tecnico.find(:all)
@auxiliares = Auxiliar.find(:all)        
@empleados = Empleado.find(:all)
end

La salida del log es: Empleado Load (0.000882) SELECT * FROM personas WHERE ( (personas.type = ‘Empleado’ OR personas.type = ‘Tecnico’ OR
personas.type = ‘Auxiliar’ ) )

En este caso perfecto.

Pues… me huele a que AR se estÃ¡ haciendo un lÃo al buscar las
subclasses y que sÃ³lo sabe encontrarlas si estÃ¡n cargadas en el espacio
de objetos. Imagino que haciendo un require inicial de cada una de las
implicadas (en el environment, por ejemplo), o lanzando un
Persona.find(:all) inicial para que te cargue todas las clases (por lo
que comentabas al hacer eso te encontraba todas) conseguirÃas tener las
clases en el scope. Pero desde luego no es muy elegante… parece un
bug, lo mismo mirando por el trac de RoR encuentras algo sobre el tema.

suerte,

j

Estamos de estreno… si necesitas llevar el control de tus gastos
visita http://www.gastosgem.com !!Es gratis!!

Juan_JosSSSS_Vidal · February 6, 2007, 3:23pm

Hola,

En la columna ‘type’ es dÃ³nde se guardan cada una de las clase.

Si insertamos datos en esta tabla (con diferentes vistas para Empleado,
Tecnico y Auxiliar), en la base de datos veremos en la columna ‘type’
los nombres de las clases pertinentes: Empleado, Tecnico y Auxiliar.

No existe a nivel de base de datos ninguna relaciÃ³n entre Empleado y
TÃ©cnico Ã³ Empleado y Auxiliar.

Efectivamente, a nivel de base de datos no hay relaciÃ³n, pero ahÃ es
donde entra “la magia” de AR. Si miras el log de una query que tenga STI
verÃ¡s que en el type le mete un “OR” por cada una de las ramificaciones
que se va encontrando desde la clase en la que buscas hacia sus
subclases. AquÃ la limitaciÃ³n es que el nombre tiene que ser Ãºnico en
cualquiera de los niveles porque si no vamos a tener conflictos… pero
es una soluciÃ³n lo suficientemente buena.

Â¿Seguro? Lo digo porque he visto en muchos blogs como definen una
relaciÃ³n del tipo que digo, mÃ¡s no dicen nada de que les falle ni nada.

Y tienes razÃ³n… tal cuÃ¡l lo planteas en tu mail original deberÃa
funcionar. Si no es asÃ se me ocurre que pueda ser por una mala
definiciÃ³n de las tablas (Â¿tienen todas la columna type?) o porque estÃ©s
sobreescribiendo el campo type a mano… o si no sÃ³lo se me ocurre algÃºn
tema de versiones.

Si miras en tu base de datos, Â¿realmente todas las filas insertadas en
personas tienen el type bien puesto?

Saludos,

javier ramirez

Estamos de estreno… si necesitas llevar el control de tus gastos
visita http://www.gastosgem.com !!Es gratis!!

Juan_JosSSSS_Vidal · February 6, 2007, 7:00pm

Dije que iba a meter la pata y la metí. Como demuestras con los logs
efectivamente funciona como debería con particiones de varios niveles.
No me fijé en tu problema del modelo frente al controlador.

Parece que lo que te responde Javier sobre que las clases no parece
mal encaminado, pero en vez de en el environment o en el controlador
yo haría el require al final de la clase padre (haría el require
‘empleado’ en persona.rb y los require ‘tecnico’; require ‘auxiliar’
en empleado.rb), de esa forma entre la búsqueda de dependencias de
Rails y esos require cargando cualquier parte del arbol se deberían
cargar todas las clases del subarbol correctamente.

Ya nos contarás si lo consigues hacer funcionar.

Juan_JosSSSS_Vidal · February 6, 2007, 7:43pm

Hola.

Parece que es un problema de momento sin resolver. Echale una ojeada a

http://dev.rubyonrails.org/ticket/4730

Al final tienes una sugerencia de soluciÃ³n.

Saludos

Daniel R. TroitiÃ±o escribiÃ³:

cargar todas las clases del subarbol correctamente.

Ya nos contarÃ¡s si lo consigues hacer funcionar.

Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es

‘All we have to decide is what to do with the time that is given to us’.
Gandalf.