From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 254F2BB88 for ; Tue, 19 Jul 2005 18:38:59 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j6JGcwsm009689 for ; Tue, 19 Jul 2005 18:38:58 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA17141 for ; Tue, 19 Jul 2005 18:38:58 +0200 (MET DST) Received: from alex.barettalocal.com (h213-255-109-130.albacom.net [213.255.109.130] (may be forged)) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j6JGcvOU009683 for ; Tue, 19 Jul 2005 18:38:57 +0200 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by alex.barettalocal.com (Postfix) with ESMTP id F2E1F2BAA98; Tue, 19 Jul 2005 18:37:37 +0200 (CEST) Message-ID: <42DD2C51.9030005@barettadeit.com> Date: Tue, 19 Jul 2005 18:37:37 +0200 From: Alex Baretta User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Jones Cc: Ocaml Subject: Re: [Caml-list] Idea for another type safe PostgreSQL interface References: <20050718210518.GA10051@furbychan.cocan.org> <42DC9D16.1080607@barettadeit.com> <20050719115305.GA29127@furbychan.cocan.org> In-Reply-To: <20050719115305.GA29127@furbychan.cocan.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 42DD2CA2.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 42DD2CA1.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; baretta:01 caml-list:01 baretta:01 model:01 model:01 transforming:01 compiler:01 abstraction:01 tolerate:01 ...:98 interrupts:98 maintainable:98 rdbms:98 wrote:01 wrote:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 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) The FreerP Project