Re: Multiple specification of constraints

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c25bp0$30c$1_at_news.netins.net...
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:05m1c.30683$u64.30224_at_newssvr16.news.prodigy.com...
> > Any file system does CRUD. No one must be allowed to update data
> independent
> > of the "data validation service." Given that we're trying to abstract
> above
> > the level of a file system, I see no good reason to differentiate the
> "CRUD
> > services" - that's what the DBMS vendor does.
>
> The reason to do so is not to sever the relationship between the database
> CRUD services and the validation services, but to ensure the validation
> services need not require that CRUD requests be directed to them. We need
> to be able to access validation/constraint information and apply it in
cases
> that have nothing to do with the CRUD services. It is typically too
tightly
> coupled with CRUD to do this today.

Oh, I agree completely. I was referring to that when I said (somewhere) that languages are not nearly relational enough... if I had relations in my programming language (e.g. for client and non-persistence stuff), I'd be overjoyed.

> > Separating essence (the constraints) from accident (the implementation
> > language) is critical, and I hope it's the "next big thing" in software
> > development.
>
> This statement is somewhat meaningless to me -- I'm pretty sure you are
not
> saying that you would not encode these constraints in some language,
right?
> Whether that language is declarative, procedural, OO, or whatever, I just
> don't care -- that's an implementation detail. It is key that the
> constraints and the application of the constraint logic (interpretation of
> specs, if that is how it is implemented) be accessible (as "services" the
> way I view it) to the database CRUD services and any software application
UI
> services, for example.

Yes, definitely a language, though I think declarative is better because it is easier to prove and reason about, generally shorter, can be optimized more easily, etc.

I would be interested in what you mean by "accessible as services." I think services is an over-used word, and I've yet to see a good definition as such. What differentiates a service from a non-service?

> > Code generation (or direct higher-level language execution) based on
> > constraints doesn't give them as much of a choice in the matter.
>
> Of course I would prefer to see it as giving them the full choice in the
> matter.

We might be talking about different things - I prefer not to give developers the choice to get around constraints that the designers and analysts have agreed are critical for the business.

> > The constraints can be read up-front; JSPs and ASPs are
> > dynamically-generated GUIs, and can read whatever they like on the
server,
> > before the HTML is streamed to the browser. The app build process can
use
> > the DBMS to generate much, so the code won't run slower than something
> with
> > hard-coded duplicated constraints. The structure of your database is
going
> > to change far, far less than its contents.

I was unclear here - I meant specifically generate using the constraints defined in the (R)DBMS.

> why would we gen code from the DBMS for use with the GUI and not think of
> gen'ing code for similar applications of constraint logic with the CRUD
> services? Simply RUN (not gen) the same services for both.

Not sure I know what you're saying here, but one reason might be to accomodate technology evolution: "Hey!" says the CEO. "Let's do .NET instead of J2EE! Cool!" Etc.

> And thank-you for taking the questions seriously and not responding with
any
> "stupid" accusations, Eric!

Not a problem...

> > Not I. A database is defined by constraints and validation - decouple
> them,
> > and you have what we already have: file systems. You have what DBMSs
were
> > created to abstract above! But again, a good topic.
>
> My intent with the "decoupling" suggestion is not to make it so that CRUD
> services do not make use of the validation services (multiple negatives
> there) but to ensure that these validation/constraint services are
available
> wherever they are needed in software applications so they are not
> duplicated.

That sounds different than what you were saying before... I thought you were specifically separating validation from CRUD.

What I think we agree on:
1. that validation services (I'd say constraints) are useful animals with implications throughout the app
2. that manually keeping multiple tiers in sync with respect to these contraints is a poor use of time

• Eric