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

[Kirill Zaborsky]

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 <s9gf4ult at 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 at 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 at googlegroups.com.
> To post to this group, send email to haskell-cafe at googlegroups.com.
> Visit this group at http://groups.google.com/group/haskell-cafe.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130731/363b3c55/attachment.htm>