From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA13891; Fri, 30 Jan 2004 12:41:57 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 MAA14046 for ; Fri, 30 Jan 2004 12:41:56 +0100 (MET) Received: from rabelais.socialtools.net (rabelais.socialtools.net [81.2.94.243]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id i0UBftP08176 for ; Fri, 30 Jan 2004 12:41:55 +0100 (MET) Received: by rabelais.socialtools.net (Postfix, from userid 108) id 59EFF23343; Fri, 30 Jan 2004 11:41:55 +0000 (GMT) Received: from socialtools.net (chaucer.socialtools.net [81.2.94.242]) by rabelais.socialtools.net (Postfix) with ESMTP id 6864923341; Fri, 30 Jan 2004 11:41:54 +0000 (GMT) Message-ID: <401A4302.7030104@socialtools.net> Date: Fri, 30 Jan 2004 11:41:54 +0000 From: Benjamin Geer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-gb, en, fr, it MIME-Version: 1.0 To: Vitaly Lugovsky Cc: Inria Ocaml Mailing List Subject: Re: [Caml-list] PostgreSQL-OCaml 1.0.1 References: <20040128232131.GA22126@fichte.ai.univie.ac.at> <20040129200653.GA14321@redhat.com> <4019F0B1.6050204@gradient.cis.upenn.edu> <401A30ED.6090007@socialtools.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on rabelais.socialtools.net X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 1.0.1:01 vitaly:01 lugovsky:01 abstractions:01 flaws:01 abstraction:01 low-level:01 abstraction:01 low-level:01 wrote:03 interface:03 rewrite:04 uses:06 problem:07 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Vitaly Lugovsky wrote: > And what's a problem? Write a portable layer, which provides > YOUR application-oriented abstractions. More code means a more expensive, more time-consuming project. Managers see that as a bad thing. JDBC has many flaws, but it has enabled us to complete projects in a small fraction of the time that we would have needed if we had had to write our own portable database abstraction layer, using the low-level interface to each database. Moreover, the absence of a *standard* database abstraction layer makes it impossible for people to write standard libraries that perform database access. >>We simply cannot afford to rewrite and maintain all our >>database-related code for every one of those databases. > > It can't be so large. Fine-grained layer always contains no more > then a dozen of low-level entities. One of our applications contains millions of lines of code and uses thousands of database tables. Ben ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners