Re:Re: [Proyecto] Migrar PL/Java a PL/PGSql

Inicio Foros Foro principal Desarrolladores [Proyecto] Migrar PL/Java a PL/PGSql Re:Re: [Proyecto] Migrar PL/Java a PL/PGSql

#35771
Javier Ader
Participante

Buenas. Ahí subí CashLineAvailable y un test sobre la misma
http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/raw-file/4dd49f57f754/CashLine/cashLineAvailable.sql
http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/raw-file/4dd49f57f754/CashLine/tests-cashline.sql

Supuestamente están todas (ok, faltan algunas, pero no tienen mucho sentido y me parece que no se usan o directamente no funcionan; por ej, la función para obtener la MAC del servidor, la versión de openxpertya!?). Después subo un script que instala todas las funciones a la vez (en las que di dos opciones, pongo la que supongo que es la correcta, sin importar si es identica a la version de PL/Java; en ese caso de querer usar la otra, se puede correr el script global y despues el de la funcion particular).
De cualquier manera, si se plantea un migración total, pienso que antes habria que seguir los siguientes puntos, alugnos de los cuales no tienen que ver directamete con PL/Java, pero los afecta:
1) O arreglar las vistas rv_c_invoice y rv_c_inovicetax para que retornen lo mismo que antes de la corrección de la función charAt o dejarlas como están (posiblemente, el nuevo funcionamiento sea el correcto…). No investigue mucho el uso de estas vistas y sus dependientes, pero me da la sensacion que solo afectarian a algunos reportes (simplemente algunos montos ahora van a ser negativos, por ej, para notas de credito)
2) Definir como se calculan los descuentos sobre facturas: la lógica en PL/Java actual no tiene sentido para descuentos en caso de que la factura tenga asociado un esquema de vencimiento valido; y, en caso de que no tenga un esquema de vencimiento valido (el calculo del descuento se da a partir del termino de pago asociado), la fecha en que se aplica el descuento esta mal calculada (no se calcula con respecto a la fecha de vencimiento de la factura, si la fecha en que fue facturada). En este caso puse dos versiones PGSql de de InvoiceDiscount que la que es afectada.
3) Notar que bomPriceXXX actual deshabilita la funcionalidad de poder poner precios para determinado (producto,conjunto de atributos). Esto no se si se esta usando, pero no creo que sea un gran limitación: un producto bajo distintos conjuntos de atributos típicamente tiene que tener el mismo precio.
4) InvoiceOpen ya no toma el monto total de la factura via C_Invoice_V, siempre lo toma desde GrandTotal directamente; esto porque se asume que la suma de vencimientos de pagos necesariamente es igual a GranToal (el codigo MInvoice hace que esto se cumpla; si no se cumple, entonce el esquema de vencimientos no es tenido en cuenta tampoco en C_Invoice_V); tambien, tampoco hay “mltiplicadores”; todos los montos relacionados se asumen no negativos, sin importar “el tipo” de factura (en particular C_Invoice.GrandTotal, y C_AllocationLine.Ammount y la suma C_AllocatinLine.Amount +C_AllocatinLine.Discountamt+C_AllocatinLine.Writeoffamt )
5) En caso de los pagos (C_Payment), creo que los montos también son actualmente no negativos: el “sentido” del pago, se podria determinar por IsReceipt; creo también que la ventanas actuales Order de Pago y Orden de Cobro generan montos positivos para los C_Payments. Aca ya tengo mis dudas (me he econtrado algunos “Contra Movimientos”!? con monto negativo… ) ; hay codigo que claramente puede setear estos montos a valores negativos , pero creo que es codigo viejo o hay algo que no estoy teniendo en cuenta. En cualquier caso, si se permiten montos negativos , entonces habria que determinar que deberia retornar funciones como PaymentAvailable y PaymentAllocated.
6) Redefinir todas las vistas que referencian a las versiones “numeric” de las fucnioes, para que pasen a usar las versiones “integer” (estas vistas parecen ser viejas, ya que considera que los ids de las tablas son de tipo numeric). No son tantas:
-rv_warehouseprice : (por ej, las tres bomPriceXXX(numeric,numeric) por sus correspondientes bomPriceXXX(integer,integer)
-rv_mpc_order_bomline
-rv_mpc_order_storage
-c_payselection_chek_v
-c_payselection_chek_vt
-rv_cash_detail
-rv_projectcycle
-rv_payment
-TOdas las que referencian a ProductAttribue(numeric) (ok, aca hay como 10, despues completo)

7) Eliminar todas las versiones “numeric” (en este punto no deberia haber problemas, ya que por el punto anterior, no tendrían ninguna dependencia)

8) Eliminar las restantes funciones PL/Java; al menos yo no le veo sentido o no funcioan
-libertya.charat(source “char”, pos integer) RETURNS “char”
-libertya.charat(p_string character varying, p_pos numeric) – ESTA NO ESTA en PL/Java, pero tira un error; se tiene que usar la nueva charAt
-libertya.documentno(p_mpc_mrp_id integer) : esto tiene que ver MPC_MRP, todo lo caul dudosamente este funcionando… Si es necesaria esta funcion, creo la version PGSql, es ejecutar solo un select.
-libertya.get_classpath(character varying)
-libertya.getmacaddresses()
-libertya.install_jar(character varying, character varying, boolean)
-libertya.openxpertyaproperties()
-libertya.openxpertyaproperty(p_key character varying)
-libertya.openxpertyaversion()
-libertya.openxpproperties()
-libertya.openxpproperty(p_key character varying)
-libertya.openxpversion()
-libertya.remove_jar(character varying, boolean)
-libertya.replace_jar(character varying, character varying, boolean)
-libertya.set_classpath(character varying, character varying)

(los siguiente por ahora nunca los probe; la otra forma de lograrlo es hacer un dump solo del esquema libertya y después restauralo en otra base de datos que no tenga PL/Java instalado, como ocurre en general cuando se crea una nueva base; a eso posiblemente habria que seguirlo con comandos VACCUM , ANALIZE, REINDEX por cuestiones de performance)
9)Eliminar el esquema sqjl
10) Desinstalar el lenguaje PL/Java a nivel de la base de datos (esto creo que es conveniente porque de esta manera los procesos del servidor sirviendo a esta base de datos no cargan en memoria el runtime de java, el cual va a ocupar memoria por cada conexión de manera innecesaria)

En este punto, se habría eliminado y migrado todo lo referente a PL/Java.