2009-05-22 8 views
35

Una pregunta un poco nueva sobre las asociaciones de rieles.Rieles: belongs_to vs has_one

Tengo un modelo de error y un modelo de estado. El estado es básicamente una tabla de pares clave/valor. De las opciones disponibles, diría que Bug tiene un estado. El estado tiene más sentido. Sin embargo, de acuerdo con this

El contenido pertenece a ContentTemplate. Diríjase a y observe cómo describí el problema , y verá que funciona. Con belongs_to, la tabla acepta la responsabilidad de la clave externa . Entonces, el contenido tiene un content_template_id. Y ContentTemplate no necesita nada. Puedo señalarlo a voluntad. Hecho.

Error belongs_to El estado sería más apropiado (ya que Bug debería tomar la clave externa). Semánticamente, su ejemplo tiene sentido, pero el mío no tiene ninguno. ¿Es esto solo un capricho de los raíles donde en esta situación parece extraño, o no estoy entendiendo algo/lo estoy haciendo mal?

Respuesta

18

Sí, creo que acabas de encontrar un escenario un poco extraño en Rails. Supongo que podría ser útil ver el "estado" como una especie de categoría a la que pertenece el error, en ese sentido, tiene sentido.

+3

Supongo que es un testimonio de cuán bien los rieles funcionan semánticamente, que al llegar a esta situación yo estaba como "Debo estar haciéndolo mal" –

0

Si el estado es solo una tabla de búsqueda/relación de valores-clave, es posible que desee una relación habtm (has_and_belongs_to_many) entre el estado y el error. Con habtm, con lo que terminará obtendrá una tabla de combinación bugs_statuses que tiene columnas bug_id y status_id junto con sus tablas de errores y estados.

+0

Eso es para relaciones de muchos a muchos, que esto no es. Esto es un muchos a uno. Mi pregunta es básicamente que la redacción de esa relación solo tiene sentido en uno a muchos, no muchos a uno, y si hay una forma más elegante de manejarlo. –

+0

Entendido. Creo que mi pensamiento típico sobre "Bugs" y su "Estado" es que un error puede estar en varios estados a la vez (por ejemplo, "worksforme" y "abrir") o puede que quieras conservar el historial del estado de un error. – rnicholson

9
TABLE: 
    Bug 
    id integer 
    desc string 
    status_id integer fk 

    Status 
    id integer 
    desc string 

RAILS MODEL: 
    Bug 
    belongs_to :status 

    Status 
    has_many :bugs 
+2

El error tomaría la clave externa porque un estado puede tener muchos errores, pero un error tiene solo un estado a la vez. – Chuck

+0

Su nueva solución es cómo pensamos en la situación, pero no funcionará. Cuando hagas bug.status, buscará una columna bug_id en estado, que no existe. A has_one o has_many tiene que coincidir con un belongs_to en la clase que se está "had". – Chuck

+0

¿Cómo lo cambiarías? Siéntase libre de copiar mi respuesta en la suya y hacer cambios allí si lo prefiere. Solo tengo curiosidad por saber cómo crees que deberían ser las modelos. –

2

Usted no explicar con precisión qué tipo de relación entre el insecto y el estado que le gustaría conseguir, pero supongo que está interesado en uno de los siguientes:

  • uno-a-muchos: en este caso debería ser has_many en la clase Bug y belongs_to en la clase de estado,
  • uno-a-uno: en este caso debería haber has_one en la clase Bug y belongs_to en la clase de estado.

En ambos casos Estado contiene la clave externa. En el segundo caso, la redacción es un poco extraña, debido al hecho de que la relación de uno a uno es, de hecho, asimétrica (debe haber un FK solo en un lado).

+1

El problema es que un error no tiene muchos estados a la vez, ya sea conceptualmente o en una implementación adecuada. Conceptualmente, pensamos en un estado como * perteneciente a * muchos errores, pero Rails solo puede expresar esto como un estado que tiene muchos errores. – Chuck

+0

@chuck: Eso es más o menos. Uno a muchos vs muchos a uno. Lógicamente, bastante equivalente, pero conceptualmente hay una diferencia –

Cuestiones relacionadas