[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] gmObject problem
From: |
Horst Herb |
Subject: |
[Gnumed-devel] gmObject problem |
Date: |
Sat, 26 Oct 2002 14:21:34 +1000 |
User-agent: |
KMail/1.4.7 |
I have committed further changes;
When a row is created new (instead of fetched form the backend), the new
primary key is transparently created (save via the apropriate backend
sequence), the row is committed to the backend and the pgobject subsequently
refreshed from the backend (how is this for comfort?).
This ensures that the pgobject state is consistent with the
constraints/defaults imposed by the backend.
The big problem is:
If such an object would be part of an outer transaction (invisible to this
object), and the outer transaction would be rolled back, this object would
still remain committed - which would break integrity.
One way to solve this problem is creating a temporary "limbo" table flagging
all OIDs of such risky transactions, such that the backend would roll back
all committments that are flagged in limbo if the transaction "owning" the
limbo key fails. Sounds like a lot of work... any better suggestions?
Horst
- [Gnumed-devel] gmObject problem,
Horst Herb <=