Re:Re:Posible bug en la versión del driver JDBC en uso

Inicio Foros Foro principal Desarrolladores Posible bug en la versión del driver JDBC en uso Re:Re:Posible bug en la versión del driver JDBC en uso

#34434
Javier AderJavier Ader
Participante

Bueno, editenme el título si pueden porque el error no esta en el driver si no en Libertya (lo que me confudió es que CPreparedStatement.executeQuery() al fallar el primer intento por un error semántico de la query, lo reintenta, y antes de hacer esto clarea los parámetros y por lo tanto al reejecutarlo tira el error que puse antes; esto se da en la parte que dice Try Locally; dicho sea de paso es bastante dudoso que este código sea correcto…).
La sentencia “SELECT C_BPartner_ID FROM C_BPartner WHERE AD_OrgBP_ID=? ” falla en el primer intento porque se setea el parámetro como int (PreparedStatement.setInt(int)), esto termina en un error en Postgres porque la columan AD_OrgBP_IP es de tipo character varying (no me pregunten por que…) y Postgres (al menos la versión que esta usando libertya 10.3) OBLIGA a un casting explicito entre int y character varying cuando el operador es “=” (dicho de otra manera; no tiene casting implícito entre estos dos tipos de datos). Probablemente bajo otros SMDB como Oracle esto este permitido.
Hay que remarcar que todo el código que vi que trata con este columna en particular de la tabla CBPartner asume que este columna es int y a veces string ….(a nivel de metadatos, la columna es de tipo Boton, asi que esto no trae problemas en este punto). Estos puntos si no me faltan algunos (es probable) son
MOrg.getLinkedC_BPartner_ID(): de donde viene el error que se muestra al completar una factura (pero que la factura en si misma se completa sin error)
BPartnerOrgLink.doIt(): ya que en este caso se llama a MBPartner.setAD_OrgBP_ID(int); pero en este caso el metodo es definido en MBPartner y no heredado de la clase generada automáticamente (ahí si correctamente, el tipo de esta columna es string)
BPartnerOrgUnLink.doIt(): usa un “mezcla” …. por un lado usa el getter de tipo int definido en MBPartner; pero al momento se “deslinkear” la entidad a una organización , usa el seter definido en X_C_BPartner (en realidad lo hace Java por sobrecarga de métodos; al ser llamado setAD_OrgBP_ID con parametro null el cual va a parar al seter dado en X_C_BPartner ya que este tiene parámetro string…)

En los dos ultimos casos, la cosa creo que funciona; mal o bien, siempre se castea entre strigs e ints previo a las modificaciones en la base de datos (incluso si no se hiciese la conversión creo que funcionaria de todas maneras ya que los updates en PO no se hacen usando parametros de un prepared statement… creo…). Ahora, en el caso MOrg.getLinkedC_BPartner_ID() se falla….

No se cual será la solución correcta; si redefiniar la columna en base de datos a int y dejar de hacer la conversion de int a string en MBParnter (y que los dos procesos se modifiquen acordermente) o modificar MOrg.getLinkedC_BPartner_ID() para que no use un parámetro de tipo int si no de tipo string…
Si se optase por lo último MOrg.getLinkedC_BPartner_ID() podría quedar asi:

Code:
public int getLinkedC_BPartner_ID() {
//TEST: Comentar el siguinte if y la llave que cierra para que MOrg
// NO chacuie la entidad linkeada
if (m_linkedBPartner == null) {
//bug: se debe convertir getAD_Org_ID a string Y NO llamar directamente con
//el int. La columna AD_OrgBP_ID es de tipo character varying NO int
int C_BPartner_ID = DB.getSQLValue(null,
“SELECT C_BPartner_ID FROM C_BPartner WHERE AD_OrgBP_ID=?”,
Integer.toString(getAD_Org_ID()) );

if (C_BPartner_ID < 0) { // not found = -1 C_BPartner_ID = 0; } m_linkedBPartner = new Integer(C_BPartner_ID); } return m_linkedBPartner.intValue(); }

Lo testie y anda (la clave está en Integer.toString(getAD_Org_ID()) ). De paso, como está puesto en el primer comentario del código, no se si es muy correcto que se cachee la entidad asociada a un organización por obvias razones (si desde otro cliente se “deslinkea” o se “linkea” el cliente actual sigue viendo las cosas como antes…)

PD : gravedad del bug? ni idea, pero me parece que para el uso común no tiene grandes implicaciones (la entidad linkeada a una organización se usa para generar automáticamente “contra documentos”… un concepto para mi gusto muuuy esotérico jajaja y la verdad que no se si se usa en muchas instalaciones)