IreneKnapp/direct-sqlite — pull request #10 by joeyadams (2012-08-17 07:19:41+00:00)
Title: Split FFI bindings into a separate package

I made a new package for `direct-sqlite`'s FFI bindings and enumeration types, but haven't released it to Hackage yet. I'm waiting for a response to this pull request first.

https://github.com/joeyadams/direct-sqlite-bindings

This means [direct-sqlite][1] can focus on value marshaling and error handling, without having to worry about foreign imports and enumerations. It also means [persistent-sqlite][2] and [direct-sqlite][1] can share the same copy of sqlite3.c without breaking any existing APIs.

[1]: http://hackage.haskell.org/package/direct-sqlite
[2]: http://hackage.haskell.org/package/persistent-sqlite

This pull request updates `direct-sqlite` to use `direct-sqlite-bindings`. It does not change `direct-sqlite`'s API, except for a couple bug fixes:

* In `bindInt`, use `sqlite3_bind_int64` instead of `sqlite3_bind_int`,
to avoid truncation on platforms where `CInt` is smaller than `Int`.

* Clarify, in the documentation, that `bindParameterCount` returns the index of the last parameter, which isn't necessarily the number of parameters.

In `direct-sqlite-bindings`, I use newtype wrappers to distinguish among the various integer types in the API. For example:

foreign import ccall "sqlite3_bind_blob"
c_sqlite3_bind_blob
:: Ptr CStatement
-> CParamIndex -- ^ Index of the SQL parameter to be set
-> Ptr a -- ^ Value to bind to the parameter.
-> CNumBytes -- ^ Length, in bytes. This must not be negative.
-> Ptr CDestructor
-> IO CError

This makes the function signatures much easier to understand. It'd be nice to have similar newtypes in `direct-sqlite`, but I wanted to avoid breaking the existing API for now.