Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS

From: Brian <brian_at_selzer-software.com>
Date: Thu, 23 Sep 2010 18:51:27 -0700 (PDT)
Message-ID: <03b3da0c-0456-4903-bbbb-f0485fd09f85_at_j2g2000vbo.googlegroups.com>


On Sep 20, 5:45 pm, paul c <toledobythe..._at_oohay.ac> wrote:
> On 20/09/2010 12:44 PM, Brian wrote:
>
>
>
>
>
> > On Sep 20, 12:42 pm, paul c<toledobythe..._at_oohay.ac>  wrote:
> ...
> >> All the original post shows is that it is possible to paint oneself into
> >> a corner with rigid preconceptions.  The supervisor doesn't need to
> >> muddle two different situations/relation values in one database
> >> transaction.  He could just as easily amend the 'first' work order in
> >> one transaction and amend the 'second' one in another transaction, or he
> >> could be provided with an interface to do that.  Nothing in the given
> >> schema relates or 'pairs' the two work order numbers. There might well
> >> be an application requirement that needs to be stated, for the
> >> supervisor to make such corrections.  In fact, given the stated
> >> requirements such as they are, there would be nothing illogical in the
> >> supervisor amending the 'second' one first and the 'first' one second or
> >> a different supervisor amending one or the other.
>
> > This is completely incoherent.  To what exactly are you referring when
> > you say that he could easily amend the 'first' work order in one
> > transaction and amend the 'second' one in another.  Are you saying
> > that some constraints should be enforced by the application?  That's
> > what it sounds like you're saying.
>
> Mutual, I don't know how one could conclude that one transaction to undo
> a mistake and another to make the correct entry have anything to do with
> application constraints.  I wish somebody here would tell me just which
> of the stated constraint(s) prevent that.- Hide quoted text -
>
> - Show quoted text -

You are suggesting that a single transition can be transformed into a series of transitions. Suppose that you're right, and a transition consisting of a single update can be transformed into a delete transition and an insert transition. For example, employee #23, Mike Smith, got a pay raise, so his hourly pay rate is increased from $13/ hour to $14/hour. On your suggestion, the first transition would remove all trace of employee #22 from the database, so the query "is the name of employee #23 Mike Smith?" would be false until the second transition completed. What if there were foreign key constraints, say from LABOR to EMPLOYEE? Does the scope of the delete expand to include references along the paths of inclusion dependencies?

If it were somehow possible to transform a single transition into a series of transitions, then the burden of enforcing business rules would shift to the application, since it would be the application that specifies the order if the individual transitions in the series. Received on Fri Sep 24 2010 - 03:51:27 CEST

Original text of this message