Definir el esquema en el ORM

Coordinator
Jul 20, 2007 at 9:31 PM
Edited Nov 4, 2007 at 4:51 PM

El problema


El ORM de Wrokflow Magic no está preparado para detectar errores de definición en el esquema de la base de datos.

Si se intenta trabajar con un esquema mal definido atravez del ORM, la herramienta intentará ejecutar consultas (SELECT/UPDATE/INSERT/DELETE) que no serán correctas. Esto provocará un Kernel Error Message indicando cuál es la consulta que no está pudiendo ejecutarse. Posteriormente, es probable que ocurra una excepción en la aplicación y ésta se cierre.

La excepciones ocurridas por mala definición en el ORM no se consideran un bug crítico pues se le presentarán solamente al implementador si éste desarrolla mal la herramienta. Sería crítico que el ORM falle sobre un esquema bien definido.

La solución


A continuación se enumeran algunos tips que deben considerarse a la hora de definir el esquema.

  • El orden de los campos, establecido por el atributo Posición, debe coincidir con el orden de los campos en la tabla.

Esto se debe a que ODBC presenta dificultades para realizar un SELECT sobre los campos de una trabla en un orden diferente al que se definieron en el esquema.
Es muy común que los implementadores quieran utilizar el atributo Posición paraestablecer el orden en que los campos se visualizan en la ViewUI. Pero esto suele traer problemas.
Lo que se propone para un futuro es implementar un nuevo atributo de las Properties (digamos, Posición para Visualización) que se utilice para definir su posición en la ViewUI.

  • Para las propiedades de tipo ENUM o PTR deben definirse los atributos classreferenced y fieldreferenced

  • Para las propiedades de tipo LIST deben definirse los atributos classreferenced, fieldreferenced y key_referenced

  • Para los campos que son obligatorios debe definirse el atributo init_value

Cuando el ORM recibe una instrucción CreateObject, hace un insert en la tabla, asignandole a cada campos el valor definido en el atributo init_value, solamente si este atributo tiene definido algún valor.
Ocurre que si no tiene definido ningún valor, y el campo es obligatorio, la instrucción INSERT fallará.

  • Para la propiedad id que actúe como PK, el alias debe ser id (en minuscula).

  • La versión 1.0.x tiene dificultades para definir una tabla con clave primaria compuesta

Cuando se tiene una relación N:N entre dos tablas (p.e. tablas A y B), lo normal es utilizar una tabla intermedia que tenga solo dos campos (idA, idB) que forman su clave primaria. En la versión 1.0.x este esquema presenta dificultades a la hora de armar algunos querys dinámicos. Por tal motivo, se recomienda que la tabla intermedia tenga su propio campo id como clave primaria, y luego se definan las dos claves foráneas idA e idB en forma independiente.