Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS

On Sep 20, 9:46 am, Erwin <e.sm..._at_myonline.be> wrote:
> On 20 sep, 15:28, Brian <br..._at_selzer-software.com> wrote:
>
>
>
>
>
> > 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 set-
> > based relational operator?
>
> > It doesn't matter that tuple-level operations occur under the covers
> > in an implementation.
>
> That is exactly where you have a problem.
>
> EXTEND and RESTRICT and in fact NOTHING AT ALL in TTM (and now read
> this next word very carefully) *_EXPOSE_* tuple-at-a-time stuff to the
> user.
>
> Your idea _does_ expose tuple-at-a-time stuff to the user _exactly
> because_ one transition path can be accepted and another one can be
> rejected, even if those two transitions start with the same database
> value and would end with the same one (well, if both were accepted, of
> course).

I can't see how it does. Each component operation of a multiple assignment that consists of just INSERTs, UPDATEs, and DELETEs is a set-based operation. It is the combination of just those component operations that makes it possible to determine precisely which transition is the one selected by the user. Since it is obvious that keys cannot be relied upon to provide that precise determination, a mechanism that can be relied upon should be welcomed, eagerly-- especially if it doesn't require alterations to any relvar headings. What I propose to be made available for defining transition constraints is exactly the information that is lost when DELETEs, UPDATEs and INSERTs are translated into generic assignments, nothing more, nothing less.

<snip> Received on Tue Sep 21 2010 - 04:47:33 CEST