Re: [Gnumed-devel] gmObject problem

[Horst Herb]

On Sat, 26 Oct 2002 22:58, Karsten Hilbert wrote:
> > Sounds simple enough to implement, can anybody see any major drawbacks
> > (other than needing to know the transactional level at the time we create
> > an object)?
>
> I don't see any obvious drawbacks but am still scratching my
> head. Can you give a little bit of a less abstract explanation

In order to create a dependent record we need the primary key of the record it 
depends on, and once we get the primary key of the "master" record, it 
implies that the master has already been committed. ( With pgobject, that 
would be the case even if there wouldn't be a formal foreign key constraint 
on the back end!)

The transparent auto-commit/refresh feature automagically ensures sort of a 
transactional integrity as long as the records within an outer virtual  
"super-transaction" have a hierarchical (like for example a foreign key) 
relationship. 

So far, so good - this covers *most* cases, but I fear not *all* cases.

What if the relationship between two tables is such that neither of them makes 
sense if *any* one of the two fails to be committed? Or, if the "master" 
table doesn't make sense unless the "child" is committed too? Circular 
relationships would probably be the most likely case to happen in the real 
world. 
Unfortunately, I cannot think of any concrete scenario as an example where 
this would be the case, but these three cases would NOT be covered by my 
design.

Can anybody come up with an example where such a situation can reasonably 
happen, or is there a proof that good relational design would prevent such 
situations anyway? (I think I remember that highest degree normalized design 
would in fact prevent such scenarios, but we are not *fully* normalized after 
all)

Horst