Verificar casos de uso de PO.getAssocRoleName y PO.getFullAttributename

[GoogleCodeExporter]

Parece que ambas se usan en las operaciones sobre hasMany como aAddTo, 
aRemoveFrom, etc.

La primera en aRemoveFrom y aRemoveAllFrom, y la segunda en el resto.

¿Cuál es la diferencia?

Creo que se usan para pedir el nombre del atributo cuando hay una relación con 
rol y clase para diferenciar de otras relaciones a la misma clase usando el rol 
(nombre del atributo en la clase donde se declara el mismo).

El tema es que 1. las implementaciones de ambas funciones son distintas, 2. 
supongo que se debería estar verificando por la misma condición (usando una o 
la otra función para todas las operaciones sobre hasMany), sino se tiene un 
comportamiento ambigüo.

El único caso que puede marcar la diferencia y es el que hay que verificar es 
tener 2 hasMany de A a B.

Original issue reported on code.google.com by pablo.swp@gmail.com on 15 Apr 2012 at 7:09

[GoogleCodeExporter]

Además creo que estas operaciones deberían ir en DatabaseNormalization o en 
YuppConventions.

Original comment by pablo.swp@gmail.com on 15 Apr 2012 at 7:11

[GoogleCodeExporter]

Parece que antes codificaba el nombre de la relacion dentro de PO, pero ahora 
como los hasMany de distintas relaciones se ponen en distintas tablas, esto no 
es necesario, alcanza con que el nombre del rol de la relación con la clase B 
sea distinto.

Y parece que todas las operaciones que antes trataban de obtener el nombre del 
atributo en la clase a partir del rol, no son necesarias y ahora todo se puede 
hacer solo con el nombre del atributo que está declarado en A.

Original comment by pablo.swp@gmail.com on 15 Apr 2012 at 6:47

• Changed state: Started

[GoogleCodeExporter]

Revisar si el método attributesOfSameRelationship es necesario porque utiliza 
la misma notación de relación que las operaciones que saqué de PO 
getAssocRoleName y getFullAttributename, y parece que tampoco sirve para nada.

Ver quien la usa y para qué.

Original comment by pablo.swp@gmail.com on 15 Apr 2012 at 9:51

[GoogleCodeExporter]

Antes de seguir sacando operaciones, verificar casos de bidireccionalidad 1-* y 
*-*.

Original comment by pablo.swp@gmail.com on 15 Apr 2012 at 9:59

[GoogleCodeExporter]

En bidireccional 1-* parece que no se usa eso del rol en la relación para 
diferenciar a qué relación pertenece un atributo.

Creo que se usaba para relacionar clases en relaciones bidireccionales cuando 
se cargaban de la base, que si había 2 relaciones declaradas con la misma 
clase, no haya ambigüedad y se supiera en qué relación cargar la instancia 
relacionada.

El tema es que ahora para relaciones x-* para la misma clase hay tablas 
distintas para cada relación, eso alcanza para diferenciar las relaciones. 
Además cada una de las tablas intermedias guarda si la relación es 
unidireccional o bidireccional.

Original comment by pablo.swp@gmail.com on 16 Apr 2012 at 12:37

[GoogleCodeExporter]

Hay un problema con obtener el nombre de la tabla de relacion en *-* desde el 
child si el owner tiene 2 relaciones hasMany hacia la misma clase child.

Lo que pasa es que las operaciones de PO que manejan eso, se basan en que el 
programador va a declarar el atributo con el nombre de la relación separado 
por "__" del rol de la relación, así se puede saber de ambos lados de la 
relación que los roles pertenecen a la misma relación.

Esa codificación debería hacerse de forma interna, no dejarla al usuario. Y 
hay que corregir las funciones que manejaban eso en PO para que lo sigan 
haciendo, considerando que en los casos donde no se declare el nombre de la 
relación en estos casos ambiguos, se lanzará una excepción informando del 
hecho. Hoy el método PO.getHasManyAttributeNameByAssocAttribute sino encuentra 
el attr para la misma relación en la clase relacionada, tira NULL y nadie se 
entera del problema!!!

Además se debería garantizar que si tengo un modelo con más de una relación 
bidireccional entre las mismas clases, algo como 
A(a1__ab1,a2__ab2)<->(b1__ab1,b2_ab2)*B, SI a1->(b1,b2), ENTONCES se debería 
cumplir que b1->a1 y b2->a1.

Ver que los roles a1 y b1 están en la misma relación ab1.

O sea: garantizar los backlinks.

Original comment by pablo.swp@gmail.com on 16 Apr 2012 at 7:44