Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS

On Sep 21, 12:52 pm, Erwin <e.sm..._at_myonline.be> wrote:
> 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.

Transition constraints implement business rules. If the user issues an update that violates a business rule, then the update should be rejected. Period. The worries are not caused by the constraint but by the business rule that it implements. Are you suggesting that business rules should just be disregarded to make things easier for the users? If a business rule that can be enforced through the use of transition constraints isn't, then it must be enforced by the application, which means that ad-hoc updates can be used to violate the rule.

>
> states transition: {t1 t2} ---> {t3 t4}.
> tuple transition: {t1--->t3   t2--->t4} gets accepted.
> tuple transition: {t1--->t4   t2--->t3} gets rejected.
>
> You explain that (the difference between the rejected update and the
> accepted one) to a user (e.g., me) without having to resort to
> explanations that really are tuple-level.  That is, without using the
> word 'tuple', and relying exclusively on words such as 'set' and
> 'relation'.- Hide quoted text -
>
> - Show quoted text -

You haven't provided enough information to make that possible. Constraints are a matter of semantics--that is, what the data means. And not just transition constraints. Now if it is clear what the data means, as it is in the third example in my original post in this thread, then there is enough information to explain to a user what went right or wrong with his update. In one case every change to a work order sequence number in WODETAIL is reflected in the associated labor activities in LABOR and none of the dates that a labor activity was performed changed, so the transition should be accepted, In another case at least one change to a sequence number wasn't reflected in the associated labor activity in LABOR, so the transition should be rejected. In another case, at least one of the dates that labor activities were performed changed, so the transition should be rejected. Received on Wed Sep 22 2010 - 03:31:50 CEST