Re: [Caml-list] PostgreSQL-OCaml 1.0.1

[Gerd Stolpmann <info@gerd-stolpmann.de>]

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