Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS

From: Brian <brian_at_selzer-software.com>
Date: Mon, 20 Sep 2010 06:28:58 -0700 (PDT)
Message-ID: <1b022f62-1e8b-41ff-8100-4cc26871392a_at_k13g2000vbq.googlegroups.com>


On Sep 20, 8:55 am, Erwin <e.sm..._at_myonline.be> wrote:
> On 20 sep, 14:15, Brian <br..._at_selzer-software.com> wrote:
>
>
>
>
>
> > On Sep 20, 5:56 am, Erwin <e.sm..._at_myonline.be> wrote:
>
> > > On 20 sep, 10:40, Brian <br..._at_selzer-software.com> wrote:
>
> > > > Is it so difficult to grasp that two different
> > > > propositions at different times can reference the same concrete
> > > > object?
>
> > > No, that is not difficult to grasp at all.
>
> > > It seems much more difficult for you to grasp that this is completely
> > > besides the point and completely irrelevant.
>
> > > > And by extension, is it so difficult to grasp that it should
> > > > be possible to match tuples in a relvar as it was prior to an update
> > > > to tuples in the database as it would be if the update were to
> > > > succeed?
>
> > > That may perhaps be possible.
>
> > > But once again, you seem to fail to realize that what you are
> > > advocating is precisely an update mechanism that operates at the tuple-
> > > level, and that that is in violation of the important prescription
> > > that all updates are set-level.
>
> > That is NOT what I'm advocating.  The Tutorial D operation
>
> > UPDATE <relvar target> [WHERE <bool exp>] ( <attribute assign
> > commalist> )
>
> > is set-based.  DELETE and INSERT are set-based.  The EXTEND relational
> > algebra operator is set-based.  Each of the additional relvar names I
> > propose refers to sets of tuples, so constraints that employ them can
> > use set-based relational operators.
>
> > <snip>- Tekst uit oorspronkelijk bericht niet weergeven -
>
> > - Tekst uit oorspronkelijk bericht weergeven -
>
> Yet within the update operations, you want matching of individual
> tuples using mechanisms that go beyond comparison of key values, to
> the effect that some database update that replaces a before state {t1
> t2} with an after state of {t3 t4}:
>
> - could be rejected by said mechanism if the transition happens to be
> t1->t3 / t2->t4
> - but could be accepted by said mechanism if the transition happens to
> be t1->t4 / t2->t3
>
> How can you possibly claim that such a mechanism would NOT be tuple-at-
> a-time ?

I refer you to TTM, Third Edition, page 39. Read the section about Extend. Would you agree that EXTEND is a set-based relational operator? I also refer you to page 111. Read the paragraph that describes <where>. Take particular note of the words, "evaluated for each tuple of r in turn." Would you agree that Restrict is a setbased  relational operator?

It doesn't matter that tuple-level operations occur under the covers in an implementation. What matters is that the users can issue database updates using set-based operations and that transition constraints can be declared using set-based relational operators.

All I'm proposing is that we harness information that the user is already supplying to determine exactly which transition is the one / the user selected./ Received on Mon Sep 20 2010 - 15:28:58 CEST

Original text of this message