Re: [Caml-list] SQL engine in OCaml with client side cache

[Gabriel Scherer <gabriel.scherer@gmail.com>]

> You don't seem to like SQL much, which is surprising as it is kind of
> isomorphic to comprehension of sets (of tuples). That's why F# added
> first class SQL support with comprehension-like syntax
>   http://msdn.microsoft.com/en-us/library/hh225374(v=vs.110).aspx

This may be a little off-topic (but who cares at this point?), but
I'll take the chance to do some self-advertising here.
We (Jerôme Vouillon and I) have done something related a few years
ago: Macaque, a DSL for writing typed and composable SQL queries in
OCaml, in a comprehension syntax.
  http://macaque.forge.ocamlcore.org/
  http://darcs.ocamlcore.org/repos/macaque/README

The comparison is that we also have something capable of typing SQL
queries as parts of OCaml programs. It more or less stops here, this
project is much less mature than the excellent LINQ work: it's mostly
a research prototype (with a very short development time: three
months) that hasn't been put to real use, mostly by lack of interested
users; it's understandable that the interest of the approach doesn't
compensate the cost of using a small, feature-restricted and
relatively arcane library when we have relatively solid SQL bindings.
By limitation of the implementation, it only supports PostgreSQL
(through the excellent PG'OCaml project, a pure-ocaml reimplementation
of the pgsql client protocol), and in retrospect the decision to use a
comprehension syntax instead of the real SQL syntax (that can be typed
all the same) is a bit unfortunate. But you may still be interested,
for example as inspiration if you decide to write some database stuff
in OCaml -- or, why not, as a user-developer.
  http://pgocaml.forge.ocamlcore.org/

For other SQL stuff in OCaml, see the Sqlite3 bindings, and possible
the "ocaml-orm-sqlite" project on top of it (whose approach is to use
code generation rather than a query DSL or combinator library; less
flexible, but result in simpler interfaces):
  http://www.ocaml.info/home/ocaml_sources.html
  https://github.com/avsm/ocaml-orm-sqlite


On Mon, Jan 30, 2012 at 12:26 AM, Diego Olivier Fernandez Pons
<dofp.ocaml@gmail.com> wrote:
>    Caml-list,
>
> [Gerd Stolpmann wrote]
>> The SQL server "solves" this by deciding on a query strategy beforehand.
>
> What ??? I thought SQL servers shipped on-the-fly optimizing compilers
> that would evaluate the query and use some heuristics (like table size
> and density) to decide in which order to execute the loops + learning
> on sequences of queries + on-the-fly reindexing.
>
> [Gerd Stolpmann wrote]
>> (Just as I side note: Missing scalability has always been a problem for
>> SQL databases. Currently, many companies go away from this technology
>> for their giant data warehouses just because of this. Of course, these
>> are not read-only, but read-write, but even having read-only scalability
>> would be a big achievement.)
>
> Mmm... I thought relational databases were a universal object, in the
> mathematical sense meaning any other object maps into them. What do
> they use if not relational databases ?
>
>> And an ugly parser :-(
>
> You don't seem to like SQL much, which is surprising as it is kind of
> isomorphic to comprehension of sets (of tuples). That's why F# added
> first class SQL support with comprehension-like syntax
> http://msdn.microsoft.com/en-us/library/hh225374(v=vs.110).aspx
>
> The idea being probably that on top of a certified whole-program
> optimizing compiler, pattern matching optimizer, multi-core capable
> garbage collector and generalized lexing/parsing library, functional
> language implementers will also have to write an optimizing SQL /
> comprehension engine.
>
>        Diego Olivier
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>