Alexey,
Regarding named parameters - another option is to use numbered parameters
like :1, :2 etc. It will help with repeated parameters at least. I didn't
understandthe first Bardur's point about "different SQL strings" though.
Kind regards,
Kirill Zaborsky
2013/7/31 Alexey Uimanov
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.