cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Flow Layer Database API
Date Tue, 04 Mar 2003 11:47:28 GMT
Antonio Gallardo wrote:
>>On a personal note, it is unfortunate because I think your new
>>techniques will be more attractive to my Client! Even though it may not
>>be the best way to work, they will find it easier to understand, being
>>closer to what they used to do. So even though I might prefer O-R
>>Mapping, I don't think they will.
> 
> I think O/R Mapping at the first sight looks a doom. But when I closer see
> it. It is the same stuff we do when we write modular Database Actions. The
> database.xml is a real O/R mapping without Beans.

Ok, let me tell you something. I've done consulting for a company that 
relies rather havily on AS/400 machines. For those of you that don't 
know it, AS/400 is soooooo relational-oriented that even the filesystem 
is bunch of tables.

They rely on SQL so much thay have SQL-wizards in house that program in 
RPG (think about a horrible programming language... mix it with cobol... 
stir... not even close!) as you and I speak. Ah, note that AS/400 has a 
8.3 char limitation on variable names, so you have wonderful things like

  select ASNAMEW, AWCHORD from FOCLI2

In short, their business logic is RPG+SQL, *that* kind of SQL. After 
seven years (and millions of euros) of producing their own patches on 
top of a commercial ERP, and several people hired to match that 
technological needs, they have no OO in-house programmer, nor they want it.

The problem is they have to connect that data (and the business logic 
that is connected to it) on their intranet.

As weird as it might seem, any O/R tool will drive them nuts for two 
reasons:

1) none of them think in terms of objects
2) there is no E/R model of their database!
3) only a few people know enough of that database to really extract 
something meaningful.

Ok, first answer to their problem is: you are hopeless and walk away.

Second answer (that would make me look nicer and them call me again) 
would be something like Chris' solution.

This example is to shows you a few things:

1) there is no clear-cut solution to every problem. Elegance is never an 
absolute metric.

2) on the other hand, SoC *IS* an absolute metric, only that concern 
analysis must be performed on an 'ad-hoc' basis: it can't be done once 
for every potential problem space.

This said, O/R mapping is *ONE* of the ways to solve the problem of 
connecting flow logic with business logic and assumes several things:

- objects are easier to deal with than SQL by the people involved in the 
development process. This is not always true.

- it is possible (in terms of economical feasibility) to perform this 
mapping and to keep it updated. This is not always true.

- database abstraction and cross-database portability is seen as a 
value. In most cases, it's not.

- the people are willing to pay the development costs of an additional 
decoupling layer between their data abstraction and their database 
representation. In most cases, they aren't.

NOTE: SQL was invented *exactly* to provide that portable abstraction. 
Today, it's considered nothing different from proprietary language with 
lots of similarities between products in the same market niche.

The result is that people will use direct SQL mapping much more than any 
other solution.

They will do it in flow, or in SQLTransformer, or in ESQL, it doesn't 
matter where, but they will. And we can't do (nor should, if this is a 
value for them) anything about it.

Now, does this mean that there are no better alternatives? no, I don't 
think so.

Is O/R the solution? could be.

How would O/R work? so that it is as transparent as possible. This 
probably rules out Torque-like pre-compilation-based approaches, leading 
to more dynamically-oriented proxy-based approaches. So OBJ seems more 
advanced in this context.

Is O/R the solution to every datamapping problem? no way! but it might 
solve lots of issues with structured-data mapping. AS for 
unstructure-data mappings, a JSR-170-like repository will hopefully do 
the job.

But I really don't know, I just want to see people experiment and try 
things out for a while and for sure there won't be *one* 
one-size-fits-all solution, but several that will hopefully reduce their 
overlap to the bare minimum.

-- 
Stefano Mazzocchi                               <stefano@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------



Mime
View raw message