Re: Triggers Help Again

Hola a todos.

Con respecto a lo del SELECT FOR UPDATE para tratar de salvar lo de la
concurrencia en la obligacion de pago me ha quedado claro. Muchas
gracias por la ayuda :)

Con dicha idea, he leido algo mas acerca de la opcion por defecto
"READ COMMITTED" en lo que es transacciones en postgres, que lo que
hace en el caso de update o delete bloquea el(los) row(s) pedido(s)
hasta que la transaccion termine (commit o rollback). Con ello estoy
ampliando aun mas la solucion a mi problema.

Una consulta mas, aprovechando los muy buenos comentarios dados para
mi tabla que estoy diseñando. Cuando me dices :

> Otro tema que ya se ha comentado antes en la lista es que es mala idea
> almacenar valores de moneda en campos de punto flotante; es mejor usar
> NUMERIC(x, y) con valores apropiados de x e y (generalmente y=2).

Si he leido en los "data types" del postgres sobre este tipo de dato.
Pero a mi parecer pareciera que uno se "encasilla" cuando define :

NUMERIC(precision, scale)

ya que si la cantidad de digitos enteros es = precision - scale ,
hace que uno siempre trabaje con esa cantidad. Pero, y si cambia en
algun momento la cantidad de enteros ??. Por eso es que no me he
decidido aun a utilizar el NUMERIC y estoy con lo del REAL.

Me dices que ya se ha hablado de este tema en la lista, pero yo soy
nuevo en ella.

Agradeceria que me ampliaran sobre este tema, PLZ.

Gracias nuevamente.

Paolo.

On 8/20/05, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> On Sat, Aug 20, 2005 at 04:52:43PM -0500, Paolo Lopez wrote:
>
> > Para obligaciones de pago :
> >
> > llaves primarias :
> > idObligacion integer
> >
> > otras llaves:
> > nombreObligacion text
> > fechaVcto date
> > monto Real
> > tipoBanco integer
> > tipoPresencial integer
> > moraxDia Real
> > montoMora Real
> > fechaCancelacion date
> > montoCancelacion Real
> > cancelado integer
> > anulado integer
>
> No entiendo por que "cancelado" y "anulado" son integers -- que es lo
> que guardas ahi? Si son valores booleanos, deberias usar campos de tipo
> booleano.
>
> Otro tema que ya se ha comentado antes en la lista es que es mala idea
> almacenar valores de moneda en campos de punto flotante; es mejor usar
> NUMERIC(x, y) con valores apropiados de x e y (generalmente y=2).
>
>
> > La regla de pago se resume en :
> > 1) solo cancelar si no esta anulado.
> >
> > a lo que la regla 1) podria extenderla a
> > 1.1) solo cancelar si no esta anulado y no esta cancelado.
> > 1.2) solo anular si no esta anulado.
>
> El protocolo de pago seria una funcion en plpgsql similar a
>
> select into rec * from obligaciones
> where idObligacion=<llave>
> for update of obligaciones;
>
> if rec.cancelado = true
> raise exception 'ya esta cancelado'
> elsif rec.anulado = true
> raise exception 'ya esta anulado'
> endif
>
>
> Etc. Si lo haces de esta manera no tienes problemas de concurrencia,
> puesto que el lock que se toma al hacer SELECT FOR UPDATE significa que
> un solo proceso va a poder estar modificando una obligacion de pago en
> un momento dado; cualquier otro va a tener que esperar hasta que ese
> haya comprometido su modificacion, y cuando pueda ver el nuevo registro,
> ya va a estar marcado como anulado o cancelado.
>
>
> Otra cosa: por favor cuando respondas mensajes de la lista, hazlo
> siempre en la lista (con copia a la lista). Gracias.
>
> --
> Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
> "In a specialized industrial society, it would be a disaster
> to have kids running around loose." (Paul Graham)
>