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

Alexey Uimanov s9gf4ult at gmail.com
Wed Jul 31 09:22:42 CEST 2013

> 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

Named parameters might be more flexible, but it is need to think hard about
how to implement this.
If you are using named parameters you need to pass not just list [SqlValue]
as parameters,
but Map Text SqlValue or something. So named parameters will not be
compatible with unnamed and will need
separate query parser.

> 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:

What I am trying to implement is not a new migration system, but just the
common interface for
simple schema actions, here is my in-mind draft:

newtype TableName = TableName Text

data TableDescription = TableDescription
                        {tableName :: TableName
                        ,tableFields :: [FieldDescription]

class (Connection con) => Introspect con where
  getTableNames:: con -> IO [TableName]
  describeTable :: con -> TableName -> IO TableDescription
  getIndexes :: con -> [IndexDescription]

class (Connection con) => SchemaChange con where
  createTable :: con -> TableDescription -> IO ()
  dropTable :: con -> TableName -> IO ()
  addColumn :: con -> TableName -> FieldDescription -> IO ()

This typeclasses must provide database-independent schema introspection and
Migration system can be anything you want.

I also have the idea do not throw the exceptions in IO but return  (Either
SqlError a) from
all the Connection and Statement methods for safe data processing. What do
you think about ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130731/e5910ad4/attachment.htm>

More information about the Haskell-Cafe mailing list