Andreas wrote:
> Hi,
>
> will I need "nested transactions" which - as I read - aren't
> implemented, yet ?
>
> I have some objects that rely on each other.
> Each has a status like proposal, working, canceled.
>
> table-A <--- table-B <--- table-C <--- table-D
>
> Those are (1, OO) relationships,
> A status change above gets cascaded down but not upwards.
> If I try to cancel a table-A-record every "lower" record in B, C, D
> should be canceled, too, when the transaction is committed.
> Since it is possible, that I cancel e.g. a table B object only its
> children should get updated but not table-A.
>
> I thought somthing along this to cancel a type B object:
>
> BEGIN
> BEGIN
> BEGIN
> UPDATE table-D
> END
> if no error UPDATE table-C
> END
> if no error UPDATE table-B
> END
>
> Does this make sense and will it provide the necesary protection ?
I don't think it needs to be that complicated. Just wrap the whole lot
in one transaction and it will either all work or all fail:
BEGIN
UPDATE table_d ...
UPDATE table_c ...
UPDATE table_d ...
COMMIT;
--
Richard Huxton
Archonet Ltd
