Re: [Caml-list] Idea for another type safe PostgreSQL interface

[Alex Baretta <alex@barettadeit.com>]

Richard Jones wrote:
> On Tue, Jul 19, 2005 at 08:26:30AM +0200, Alex Baretta wrote:
> 
> (1) Changes to the database schema.  Does your product allow you to
> generate the appropriate ALTER TABLE ... statements when the schema
> changes?  How about upgrading an existing live database between
> versions of the schema?

I have been working on it. I was almost finished with it when I had to
switch to something else. I count on working on this during the August
break, when the rate of interrupts is much lower.

The basic technique is the following: I compare two XDBS models and
generate an /tentative/ refinement model, which, applied to the older
XDBS model, yields the second. The model is only tentative in that the
diff operator is not unique: there are many different refinements
between the same two endpoint models. The programmer is then able to
look at what `xdbs_diff model1.xdbs model2.xdbs` has generated and maybe
modify by hand to match his intuition of what the refinement should be.
The /final/ refinement is fed together with the original schema and
endpoint schema to xdbs_patch, which verifies that the refinement
applied the first schema yields the second, and, if this test is passed,
it generates the SQL code transforming the datastructure according to
the refinement.

This is the only sensibile approach, in that it allows the programmer to
stick his nose in what the automated code generation process *and* keep
track of his work on top of the automated tools' work by commiting the
refinement model to the repository.


> (2) How is the OR mapping handled?  PDL had a complex compiler which

OR? What is it?

> (supposedly) generated optimal SQL statements from object methods.  In
> practice the developers seemed to spend a lot of time writing
> hand-optimised queries.  I don't really understand what the fuss is
> about just writing SQL queries directly into code - it's the fastest
> way I've found to achieve results (if only it were type safe), seems
> reasonably maintainable, and gets rid of layers of obscure
> abstraction.

SQL is very sensible language for the manipulation of relations. General
purpose languages don't have joins as a native language construct, for
one thing. For this reason we have committed to SQL as the "Way To Go"
for accessing permanent storage from the Xcaml system. Of course, I
could not tolerate the "query-as-a-string" approach of PHP. We had to
have it compiled and typechecked, or we could not expect FreerP to scale
beyond a few dozen tables.

>>Also, the type safety does not depend on a specific implementation of
>>SQL, which is usually desireable.
> 
> I take your point, but really PostgreSQL already does everything I'm
> ever likely to want to do with a database, it's Free, stable and fast,
> and actively under development.

PostgreSQL is also my database of choice. But I know that I must also
live with "legacy" RDBMS out there--Oracle, iSeries--where I might have
to run a query every once in a while. And I don't want to do it without
typechecking.

Alex


-- 
*********************************************************************
http://www.barettadeit.com/
Baretta DE&IT
A division of Baretta SRL

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Our technology:

The Application System/Xcaml (AS/Xcaml)
<http://www.asxcaml.org/>

The FreerP Project
<http://www.freerp.org/>