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 PAA27685; Fri, 30 Jan 2004 15:58:57 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA28036 for ; Fri, 30 Jan 2004 15:58:56 +0100 (MET) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.189]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id i0UEwtv19289 for ; Fri, 30 Jan 2004 15:58:56 +0100 (MET) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Ama6g-0006bi-00; Fri, 30 Jan 2004 15:58:54 +0100 Received: from [80.129.97.162] (helo=gate.gerd-stolpmann.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1Ama6g-0006fq-00; Fri, 30 Jan 2004 15:58:54 +0100 Received: from ice.gerd-stolpmann.de (ice.gerd-stolpmann.de [192.168.0.13]) by gate.gerd-stolpmann.de (Postfix) with ESMTP id 0F10056C0; Fri, 30 Jan 2004 15:58:53 +0100 (CET) Received: by ice.gerd-stolpmann.de (Postfix, from userid 1000) id D1CE7B055; Fri, 30 Jan 2004 15:58:48 +0100 (CET) Subject: Re: [Caml-list] PostgreSQL-OCaml 1.0.1 From: Gerd Stolpmann To: Richard Jones Cc: Benjamin Geer , Inria Ocaml Mailing List In-Reply-To: <20040130104715.GA24501@redhat.com> References: <20040128232131.GA22126@fichte.ai.univie.ac.at> <20040129200653.GA14321@redhat.com> <4019F0B1.6050204@gradient.cis.upenn.edu> <401A30ED.6090007@socialtools.net> <20040130104715.GA24501@redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1075474727.1023.72.camel@ice.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 30 Jan 2004 15:58:48 +0100 X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:a6865a839c0178d9aa0ce41878507ea2 X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 1.0.1:01 gerd:01 stolpmann:01 fre:99 2004:99 dbi:99 dbi:99 mli:01 mli:01 postgres:01 postgres:01 runtime:01 baretta:01 camlp:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fre, 2004-01-30 at 11:47, Richard Jones wrote: > If people think that the mod_caml DBI approach is the right one (and > it may not be, although it certainly Works For Us), then I could spin > this off into a separate package to make it easier to install. > > This is dbi.mli: > > http://savannah.nongnu.org/cgi-bin/viewcvs/modcaml/modcaml/dbi.mli?rev=HEAD&content-type=text/vnd.viewcvs-markup > > This is dbi_postgres.mli, which is the driver we use all the time in > production at Merjis, hence the most stable / developed: > > http://savannah.nongnu.org/cgi-bin/viewcvs/modcaml/modcaml/dbi_postgres.mli?rev=HEAD&content-type=text/vnd.viewcvs-markup > > This is the driver for Perl DBDs: > > http://savannah.nongnu.org/cgi-bin/viewcvs/modcaml/modcaml/dbi_perl.mli?rev=HEAD&content-type=text/vnd.viewcvs-markup > > The interface is designed to make it quick to access databases, in the > sense that you write the minimum code necessary. It's not type safe, > in the sense that if you write garbage SQL, it won't be detected until > runtime. Alex Baretta is, I believe, pursuing an alternative approach > using Camlp4 which is supposed to be type safe. Hi, I think we really need this type of interface. I have some experience with Perl DBI, and although our company did have the need to support several database systems in the same product, this made things a lot easier, simply because you don't have to learn a new API when you switch to a another database system. So I would it really appreciate if this interface were released as independent package. Of course, I have also some technical remarks: - I don't understand why there are several ways to represent NULL. For example, what is the difference between `Null, `TimestampOption None, and `Timestamp ts where ts.ts_is_null=true? - Using host,port,user,password to identify and authenticate a connection works in most cases, but is not very wise for the long-term stability of the interface. For example, it is already possible to authenticate with X509 certificates, which cannot be expressed with this scheme. I would suggest to only have two strings, one called "system_id", the other called "authenticator". In general, these strings are interpreted by the driver, but there are conventions, e.g. "host=XXX,port=XXX" for the system_id, and "user=XXX,password=XXX" or "user=XXX,x509privatekey=XXX,x509passphrase=XXX" for the authenticator. - There is no way to pass options to the driver when one uses the Factory. I think it would be a good idea to have a string for driver options, again in the format "key=value,...". - There should be method for escaping strings (so one can generate SQL statements) - One exception should be special: That transactions are aborted because of conflicts (think of Postgres' MVCC) or deadlocks and should be repeated. I think the other possible errors can be subsumed in one Sql_error exception as it is currently done. - There should be a possibility to coerce a generic connection object back to the driver's class. This can be done by adding a method driver_handle that just raises a driver-specific exception returning the handle. This way it is possible to switch to low-level code at any time, e.g. for optimizations for certain DBMS. - Following the coding guidelines for O'Caml, methods with side-effects should have a functional type, e.g. finish : unit->unit instead of just finish:unit. This has also the advantage of making it simpler to later add optional arguments to methods. - There was the question how to handle BLOBs. I worked with DBMS where TEXT is a BLOB type. I think there should be a BLOB class like class type blob = object method length : int64 method get_chunk : pos:int64 -> len:int -> string method write_file : string -> unit end and there should be methods (of the connection) creating such BLOBs: method create_blob_from_string : string -> blob method create_blob_from_file : string -> blob I think this is the minimal BLOB interface we should support. More advanced BLOB interfaces can be implemented in the drivers. I hope we get a really good generic DBMS layer soon. Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de ------------------------------------------------------------ ------------------- 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