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 <s9gf4...@gmail.com> > 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+unsubscr...@googlegroups.com. > To post to this group, send email to haskell-c...@googlegroups.com. > Visit this group at http://groups.google.com/group/haskell-cafe. > For more options, visit https://groups.google.com/groups/opt_out. > > > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe