Note in-line
--
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
The educated person is not the person
who can answer the questions, but the
person who can question the answers -- T. Schick Jr
Next public appearances:
Jan 29th 2004 UKOUG Unix SIG - v$ and x$
March 2004 Hotsos Symposium - The Burden of Proof
March 2004 Charlotte NC OUG - CBO Tutorial
April 2004 Iceland
One-day tutorials:
http://www.jlcomp.demon.co.uk/tutorial.html
Three-day seminar:
see http://www.jlcomp.demon.co.uk/seminar.html
____UK___February
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
"VC" <boston103_at_hotmail.com> wrote in message
news:0zgRb.154071$I06.1552615_at_attbi_s01...
> Hello Jonathan,
>
> Please see below.
>
> "Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in message
> news:bv3c9o$qrv$1_at_sparta.btinternet.com...
> > >
> > > The constraint is right there, in the statement itself:
> > >
> > > update t1 set amount=amount-80
> > > where (select t1.amount+t2.amount from t1 join t2 on t1.id=t2.id) > 0;
> > >
> >
> > That's not a constraint, that's just a simple condition.
> >
>
> Well, a constraint is nothing more but a conditional expression that's
> required to evaluate to true. Since Oracle does not have database
> constraints (constraints enforced between different tables), one has to
> manually code them
>
> > The following statement works just as well on your original
> > dataset (and I suspect it would do the same thing on all the
> > commercial RDBMSs):
> >
> update t1 set amount=amount-1000
> > where (select t1.amount+t2.amount from t1 join t2 on t1.id=t2.id) > 0;
>
> Thank you for pointing out my error. The condition should rather be as
> follows:
>
> update t1 set amount=amount - the_update_amount
> where (select t1.amount+t2.amount from t1 join t2 on t1.id=t2.id) >
> the_update_amount;
>
> > I think the point you are really making isn't about
> > serializability, it's about commercial databases failing
> > to implement some features of generic constraints.
>
> No, actually my point was precisely about serializability.
I disagree - if you re-read your comments from the last
few lines you have said:
Oracle does not implement database constraints
We have to fake database constraints.
Because our fake database constaints do not work, we can construct
a demonstration of serializable transactions not working.
Ergo, serialization is the significant issue
My line is simply that the most significant failing is that database
constraints are not implemented (possibly in any commercial database),
and all you have done is show that if you don't fake database constraints
properly then you can get serialization to fail.That makes the serialization
issue
secondary to the database constraint issue
To date, every example I have seen of Oracle failing to handle
serialization properly has required the construction of an incorrect
data model, so I haven't been able to get excited about the issue.
Notwithstanding that, the point you make that 'serializable' does
NOT automatically fix update anomalies is an important one,
because the issue is more subtle than most of the fakery that
has to go on around SQL databases.
Received on Tue Jan 27 2004 - 02:46:02 CST
