Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS

From: Brian <brian_at_selzer-software.com>
Date: Mon, 20 Sep 2010 16:34:05 -0700 (PDT)
Message-ID: <0c47c91a-a9c3-4cfa-b739-ead996f8b6b4_at_a30g2000vbt.googlegroups.com>


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? Received on Tue Sep 21 2010 - 01:34:05 CEST

Original text of this message