Path: news.cambrium.nl!textnews.cambrium.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.78.MISMATCH!feeder.news-service.com!postnews.google.com!a30g2000vbt.googlegroups.com!not-for-mail
From: Brian <brian@selzer-software.com>
Newsgroups: comp.databases.theory
Subject: Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS
Date: Mon, 20 Sep 2010 16:34:05 -0700 (PDT)
Organization: http://groups.google.com
Lines: 111
Message-ID: <0c47c91a-a9c3-4cfa-b739-ead996f8b6b4@a30g2000vbt.googlegroups.com>
References: <d67dea08-45fb-493e-99fc-554028a670c0@k11g2000vbf.googlegroups.com>
 <aEylo.837$u9.818@edtnps82> <d4ae3b22-b7b8-49fb-be6e-b0ea47f44438@i17g2000vbq.googlegroups.com>
 <ea82a7fb-db65-46c1-b1c5-7521ece1765d@t3g2000vbb.googlegroups.com>
 <22b3107e-d5b0-4449-82cf-f81860cb49f4@m1g2000vbh.googlegroups.com>
 <3d9a51b4-833b-483f-a7cc-054bc4f4037c@w4g2000vbh.googlegroups.com>
 <1b022f62-1e8b-41ff-8100-4cc26871392a@k13g2000vbq.googlegroups.com> <7cf60163-fd5d-452d-8b95-0bbb3922b6fa@u13g2000vbo.googlegroups.com>
NNTP-Posting-Host: 68.73.73.118
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1285025645 16403 127.0.0.1 (20 Sep 2010 23:34:05 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Mon, 20 Sep 2010 23:34:05 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: a30g2000vbt.googlegroups.com; posting-host=68.73.73.118; posting-account=AE9LXgoAAACF8PIhanDAmLcShUHywety
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1;
 Trident/4.0; SLCC2; .NET CLR 2.0.50727; Media Center PC 6.0; .NET CLR
 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; OfficeLiveConnector.1.5; OfficeLivePatch.1.3),gzip(gfe)
Xref:  news.cambrium.nl

On Sep 20, 9:46=A0am, Erwin <e.sm...@myonline.be> wrote:
> On 20 sep, 15:28, Brian <br...@selzer-software.com> wrote:
>
>
>
>
>
> > On Sep 20, 8:55=A0am, Erwin <e.sm...@myonline.be> wrote:
>
> > > On 20 sep, 14:15, Brian <br...@selzer-software.com> wrote:
>
> > > > On Sep 20, 5:56=A0am, Erwin <e.sm...@myonline.be> wrote:
>
> > > > > On 20 sep, 10:40, Brian <br...@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 comple=
tely
> > > > > besides the point and completely irrelevant.
>
> > > > > >=A0And 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 u=
pdate
> > > > > > 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 prescriptio=
n
> > > > > that all updates are set-level.
>
> > > > That is NOT what I'm advocating. =A0The Tutorial D operation
>
> > > > UPDATE <relvar target> [WHERE <bool exp>] ( <attribute assign
> > > > commalist> )
>
> > > > is set-based. =A0DELETE and INSERT are set-based. =A0The EXTEND rel=
ational
> > > > algebra operator is set-based. =A0Each of the additional relvar nam=
es I
> > > > propose refers to sets of tuples, so constraints that employ them c=
an
> > > > 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 t=
o
> > > be t1->t4 / t2->t3
>
> > > How can you possibly claim that such a mechanism would NOT be tuple-a=
t-
> > > a-time ?
>
> > I refer you to TTM, Third Edition, page 39. =A0Read the section about
> > Extend. =A0Would you agree that EXTEND is a set-based relational
> > operator? =A0I also refer you to page 111. =A0Read the paragraph that
> > describes <where>. =A0 =A0Take particular note of the words, "evaluated
> > for each tuple of r in turn." =A0Would 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?