Así era nomás: M_Juguetes_ID estaba en el diccionario en minúsculas (y eso que lo advirtieron bastantes veces jajaja…). Lo que me confundió fue más que nada el segundo error, ya que el constructor ERA llamado y por lo tanto encontrado via reflexión (tanto en un update como en un insert), y obviamente MJuguetes.java era encontrado lo más bien. También, aún cuando se muestra este error (en la consola, no en la aplicación), los cambios realmente se persisten; supongo que antes estos casos se recurre a otro mecanismo de persistencia que “bypasa” a PO y sus descendientes.
En M_Table.getPO (528) se encuentra:
Constructor constructor = clazz.getDeclaredConstructor(new Class[] { Properties.class, ResultSet.class, String.class });
PO po = (PO) constructor.newInstance(new Object[] { getCtx(), rs, trxName });
return po;
} catch (Exception e) {
log.log(Level.SEVERE, “(rs) – Table=” + tableName + “,Class=” + clazz, e);
errorLogged = true;
log.saveError(“Error”, “Table=” + tableName + “,Class=” + clazz);
}
y pienso que lo que falla ahí no es el GetDeclaredConstructor, si no que la invocación (constructor.newInstance) en la linea siguiente dispara una excepción, porque el constructor en PO (invocado desde el constructor de MJuguetes) no encuentra la clave primaria y dispara una excepción…
La clave entonces creo que esta en (que dicho sea de paso, aparece en la traza, pero no entiendo porque en el “medio” de la misma)
at org.openXpertya.model.PO.setKeyInfo(PO.java:1391)
at org.openXpertya.model.PO.load(PO.java:1284)
at org.openXpertya.model.PO.
PO.setKeyInfo (1381-1391)
ArrayList columnNames = new ArrayList();
for (int i = 0; i < p_info.getColumnCount(); i++) { if (p_info.isColumnParent(i)) columnNames.add(p_info.getColumnName(i)); } // Set FKs int size = columnNames.size(); if (size == 0) throw new IllegalStateException("No PK nor FK - " + p_info.getTableName());
el size == 0 era true al parecer porque p_info.isColumnParent daba false para todas las columnas. Supongo que para p_info una columna es “parent” si es un ID o un clave foranea (segun el diccionario de datos). La info de la columnas creo que es precomputada en POInfo.loadInfo… pero este metodo simplemetne hace un select de de inner joins sobre AD_Table, AD_Column y un par de tablas mas… y isParent para la columna termina siendo lo que diga AD_Column.IsParent en la base de datos… asi que para seguir rastreando porque no me marca algo como “parent” cuando no se respeta al convención de nombres hay que ir a mirar por otros lados (en particular el codigo que modifica el diccionario de datos)… pero bueno ya el rastreo se hace muyyyyyyy largo; obviamente en algún lugar se tiene que hacer respetar la convención…
En cualquier caso la conclusión que hago es: respetar la convención de nombres (al menos para las columnas ID, supongo también que para cualquier otra no?)… y que el constructor de una clase de persistencia de objetos sea llamado no significa mucho; hay que verificar que retorne correctamente y no con una excepción (que era lo que me pasaba a mi…)
PD : también, el segundo error que me mostraba claramente esta “mal”… el constructor se encuentra, el tema es que su invocación tira una excepción (el código debe tener un try catch similar que pueda fallar por las dos razones, pero en el catch al mostrar la causa del error solo se contempla que lo que falle sea la reflexión y no la invocación)
