Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS

On 21 sep, 01:34, Brian <br..._at_selzer-software.com> wrote:
> 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).
>
> > > 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.
>
> > All I'm answering is that it should be considered as the great
> > achievement of TTM that the user can be relieved from having to worry
> > about "exactly which transition to select".
>
> > Forcing such worries upon the user is an unnecessary complication both
> > for the user and for the system, and one from which no gains can be
> > made.- Hide quoted text -
>
> > - Show quoted text -
>
> What worries?  How is it worrysome for users to continue to use
> INSERT, UPDATE and DELETE as they have always done?- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

The worries over which particular transition they must indicate so that some particular BS-style transition constraint will not cause their update to fail.

states transition: {t1 t2} ---> {t3 t4}.
tuple transition: {t1--->t3   t2--->t4} gets accepted.
tuple transition: {t1--->t4   t2--->t3} gets rejected.