[Haskell-cafe] ANNOUNCE: hdbi-1.0.0 and hdbi-postgresql-1.0.0

[Bardur Arantsson]

On 2013-07-31 05:45, Alexey Uimanov wrote:
> Hello, haskellers. This is the first release of HDBI (Haskell Database
> Independent interface). It is the fork of HDBC.
> HDBI has some improvements in design, it also has better testing and
> performance (mainly because of using Text instead of String anywhere).
> HDBI designed to be more flexible and correct database interface.
> 
> You can find out more information in the documentation.
> http://hackage.haskell.org/package/hdbi
> http://hackage.haskell.org/package/hdbi-postgresql
> 
> I am planning to implement MySql and Sqlite drivers as well
> 
> https://github.com/s9gf4ult/hdbi
> https://github.com/s9gf4ult/hdbi-postgresql
> Issues and pull requests are welcome, as well as collaboration.
> 

Looks interesting.

Just a couple of comments from skimming the documentation. Apologies, if
these are already addressed -- didn't see any mention of it from my
read-through.

Regard parameterized SQL: It might be worth using named parameters (e.g.
":foo" and ":bar" or something like that) rather than "?" as
placeholders in SQL/prepared SQL. This will make it slightly more
flexible if you need to provide different SQL strings for different
databases, but want to reuse the code which does the actual running of
the SQL. It's also more flexible if you need to repeat parameters -- the
latter is typical with PostgreSQL if you want to emulate
"update-or-insert" in a single SQL statement.

Regarding migrations: If you haven't already, please have a look at
Liquibase (http://www.liquibase.org/documentation/index.html) before
attempting to implement migrations. The most important attributes of
Liquibase are:

  a) migrations are *manually* specified deltas as opposed to deltas
     automatically derived from two snapshots of the database. Anything
     based on automatically getting from snapshot A to snapshot B *will*
     break or do undesirable/unpredictable things to data at some point.
  b) It deliberately does NOT provide migrations in a Turing Complete
     language -- IME, if you need TC migrations on a routine basis
     you're already in deep trouble and need to think more about what
     you're doing (at a "process" or "engineering" level). If you
     *really* need to, you *can* extend it do custom migrations via
     code, but the barrier to entry is sufficiently high that you'll
     rarely be tempted unless you *really* need it and the migration
     step is likely to be reusable.
  c) the concept of "contexts" (see the documentation) which allows
     you to vary the migrations across different environments as
     needed. (This is definitely open to abuse, but when you need it
     you *really* need it, IME.)
  d) It can also generate full SQL for "changes-about-to-be-applied"
     so that you can audit and/or apply them manually -- some devops
     teams need this, others may not care. A minor but important
     detail is that the generated SQL includes all the metadata for
     tracking the application of the migrations themselves.

Liquibase is the only system *I've* ever seen that is even close to
doing migrations the Right Way According To Me(TM). (I've used it since
the 1.x days using the XML format and still haven't come across anything
that can really compete.) Liquibase certainly has flaws(*), but one
should think *really* hard about whether there isn't some existing
migrations system which is "good enough" before foisting yet another
migrations system on the world since it's highly likely to be at least
as flawed as all the existing systems in one way or another.

(Of course, being implemented in Java, there is one aspect of Liquibase
which is annoying if using it for Haskell projects: It's not very
convenient to auto-apply all migrations at startup time without some
sort of "run-this-executable-script-before-running-the-main-program"
hack. That, and you need a Java Runtime Environment installed.)

Anyway, just throwing that out there...

Regards,

/b

(*) Sub-par internal consistency checking across combinations of
contexts for changelog files being one of them. There also the fact that
it was until recently XML-based and that the the new syntaxes all have
their own problems. Maybe a Haskell DSL could lead to some real
improvements here...