Chris wrote:

I am entirely convinced of the benefit of configuring applications
dynamically from a conceptual model, be it done through code-generation
or at run-time.

We probably don't see eye-to-eye on how to represent the conceptual
model though. You seem to prefer the object model and you put up the
straw man of "schema based applications" as the only alternative,
seemingly to clinch the point.

The real alternative is a formal logical model that captures as much of
the informal conceptual model as possible (excluding the mystical bits).
When you refer to a "schema" and "table structures" it is clear your
schema based application is an SQL database implementation, which is
VERY far from being a complete logical model even if it's formal.

The great disadvantage of the so-called object model is that it is
entirely undefined. We all sorta, kinda "know" enough about it to get
on, but if we start digging into what makes it tick, as we must if we
want to automate application generation to the extent possible, we
discover there is no underlying theory to it all. There is nothing that
can help us through it when intuition runs out. It is (to misquote
Bertrand Russell's apocryphal old lady, among others) bollocks all the
way down. That's one reason we have to write so much procedural code to
fill in the gaps.

First order predicate logic and set theory on the other hand, have truly
impressive theoretical underpinnings to help us.

If the SQL schema really were the alternative you'd be right to claim
the object model has more potential. But it's not and there are real
problems with the object model. Sooner or later we're going to stop
screwing around with object models and we'll back to the relational
model (but emphatically *not* the comprehensive botch we call SQL). I
will admit that there's a rich collection of products that help us to
be productive with the "object model" but they just make a crappy
situation less awful; they're not the best we can aspire to.

--
Roy

UK Ingres User Association Conference 2011 will be on Tuesday June 7 2011.
Register at http://www.regonline.co.uk/ukiua2011

On Mar 28, 5:59*am, Allan Biggs <alla... (AT) iname (DOT) com> wrote:
A bit like dclgen for abf?

weasel wrote:

Sounds like. But a bit of a failure of aspiration IMO. Why expect to
have to update the code at all? Why expect to have to write it
"well" in the first place? Ideally it should be sufficient to recompile
the application, like if you defined an ABF record type based on a
table definition.

ABF (and QBF) did a lot of things right considering the feeble power of
the hardware available in the late 1970s. One day we might re-visit
the approach they took, using the incomparably better interfaces
and colossal power we've got now.

--
Roy

UK Ingres User Association Conference 2011 will be on Tuesday June 7 2011.
Register at http://www.regonline.co.uk/ukiua2011

A healthy argument on SQL versus Object based applications, excellent!
Prepare to be .....

............ disappointed :-p We may have similar views on this after
all :-)

Whilst application development isn't a large part of my job, I've
written a few ;-) In all the apps/tools I've written I've only got
one application where I wrote an object model first. I actually hate
writing object models. I prefer, when possible, to use tools to create
code which was what I was trying to articulate rather than a
preference for a specific implementation of this approach (I think my
mistake was ONLY using object based examples, dclgen and Vision are
good non-object examples but they are slightly outclassed in terms of
features compared with some of the new frameworks available today).

In an ideal world the same modeling tool would be used to generate
object models, C structs, SQL DDL, etc. Usually what happens is you
need to add plugins to fill in the gaps and/or writing your own tool
set. XMI has helped here a lot with interoperability between tools.

In a attempt to defend object model based applications

I avoided using the word object until talking about object models (and
by implication ORMs) as an example of model based approach to
application development with code generation. Frame works that use
ORMs are the most popular example of auto code generation that is out
there today. I think most people have heard of it which is why I used
it as an example. However ORMs are often presented as a great tool for
new users as it abstracts away "difficult" (it isn't really that
complex) SQL, which really isn't an accurate or honest representation.
As a slightly artificial example (but one that shows a difference in
procedural versus relational approaches), for the same reason one
wouldn't write code like:

for x in 1 to 5000
select ... from customer where id = :x

With an ORM it would be foolish to write:

for x in 1 to 5000
customer.get(id=x)

Running many small selects when one select would return the same rows
is just something one doesn't do! :-)

I think it is more obvious when looking at the first example above
that this is not sensible (the SELECT makes it clear a DBMS call is
being made), the second example gives no indication that a DBMS is
involved.


This is absolutely correct! ORMs main purpose in life is to make OO
access to relational data (the other stuff like free input validation
is due to a model generating code rather than object). To use an ORM
effectively you have to have a modicum of knowledge about relational
databases.

The best application frame works can do at the moment is make it
possible to create a skeleton application that a real human can then
customize, the good frameworks make it possible for later model
changes to not screw up the user generated code.

If you where to press me I'd wouldn't say that I prefer object models
as I'd rather have a tool generate the object model from some master
model. However at the moment, object model based application
(frameworks) appear to be the current best option for auto generating
a lot of boiler plate code which offers the possibility of model
changes and "free" code changes.

Chris