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 changing. 

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 ?

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

--
You received this message because you are subscribed to a topic in the Google Groups "Haskell-cafe" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/haskell-cafe/9X2J65gXGXs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to haskell-cafe+unsubscribe@googlegroups.com.
To post to this group, send email to haskell-cafe@googlegroups.com.
Visit this group at http://groups.google.com/group/haskell-cafe.
For more options, visit https://groups.google.com/groups/opt_out.