recommendation for (best) sqlite3 bindings

Hello! We are looking for recommendation which Haskell bindings for sqlite3 to use for destkop GUI app where we want, among other things to store *.png and/or *.jpg images. (Yeah, I know about the hint to store iamges in the filesystem and just store filepaths in the db, but for portability reasons so that user can easily carry/backup database, we want everything stored in one file.) By looking at Hackage, it seems there are 3 candidates: 1) sqlite - bindings by Galois (http://hackage.haskell.org/package/sqlite) - looks quite complete & low-level interface 2) direct-sqlite - it says "It is not as complete as bindings-sqlite3 (1), but is slightly higher-level...it supports strings encoded as UTF8, and BLOBs represented as ByteStrings." and 3) HDBC-sqlite3 - higher level but without support for BLOBs. Now, based on the above it looks that 2) is the best one - not high-level as 2), but adding BLOBs support which, iirc, is missing in HDBC. Otoh, having highr-level abstraction ala HDBC is nice, although at the moment we believe that we won't have need to go to PostgreSQL since it means that setup would be greatly complicated for the end-user, so we're staying focused on Sqlite3. I know there are also Takusen & HSQL, but based on my past experiences when watching those two projects, it seems they aren not supported as well as the above itemized ones. Any recommendation? May I add that, according to the recent "Merge hsql and HDBC -- there can only be one!" thread, I can only "+1" for having slight less & more complete database packages. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ----------------------------------------------------------------

On Wed, Jul 21, 2010 at 7:54 AM, Gour
Hello!
We are looking for recommendation which Haskell bindings for sqlite3 to use for destkop GUI app where we want, among other things to store *.png and/or *.jpg images. (Yeah, I know about the hint to store iamges in the filesystem and just store filepaths in the db, but for portability reasons so that user can easily carry/backup database, we want everything stored in one file.)
By looking at Hackage, it seems there are 3 candidates:
1) sqlite - bindings by Galois (http://hackage.haskell.org/package/sqlite) - looks quite complete & low-level interface
2) direct-sqlite - it says "It is not as complete as bindings-sqlite3 (1), but is slightly higher-level...it supports strings encoded as UTF8, and BLOBs represented as ByteStrings." and
3) HDBC-sqlite3 - higher level but without support for BLOBs.
Now, based on the above it looks that 2) is the best one - not high-level as 2), but adding BLOBs support which, iirc, is missing in HDBC.
Otoh, having highr-level abstraction ala HDBC is nice, although at the moment we believe that we won't have need to go to PostgreSQL since it means that setup would be greatly complicated for the end-user, so we're staying focused on Sqlite3.
I know there are also Takusen & HSQL, but based on my past experiences when watching those two projects, it seems they aren not supported as well as the above itemized ones.
Any recommendation?
May I add that, according to the recent "Merge hsql and HDBC -- there can only be one!" thread, I can only "+1" for having slight less & more complete database packages.
Sincerely, Gour
For the sqlite backend for persistent, I took direct-sqlite and modified it slightly. I have a long history of using the sqlite3 C API, so the API felt very familiar to me.
If I'm not mistaken, direct-sqlite does not build as-is on hackage because it's missing a reference to the C library. However, if you take my approach and just include the code in your library, you can fix that easily enough. Michael

On Wed, 21 Jul 2010 08:06:49 +0300
"Michael" == Michael Snoyman
wrote:
Michael> For the sqlite backend for persistent, I took direct-sqlite Michael> and modified it slightly. I have a long history of using the Michael> sqlite3 C API, so the API felt very familiar to me. So, it seems you're satisfiew with direct-sqlite? What is missing in 1st package (Galois bindings)? btw, after some research, I've concluded that NOSQL (Redis, MongoDB) are not good solutions in our use-case since we want to have extensive querying support and using sqlite3 with SQL seems better option. Michael> If I'm not mistaken, direct-sqlite does not build as-is on Michael> hackage because it's missing a reference to the C library. Hmm...you're right. Apparently Archlinux package built OK; but loading it into ghci gives: ghc: /usr/lib/direct-sqlite-1.0/ghc-6.12.1/HSdirect-sqlite-1.0.o: unknown symbol `sqlite3_column_blob' Thank you. Michael> However, if you take my approach and just include the code in Michael> your library, you can fix that easily enough. It looks it's the problem with package's cabal file... Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ----------------------------------------------------------------

On Wed, Jul 21, 2010 at 8:59 AM, Gour
On Wed, 21 Jul 2010 08:06:49 +0300
> "Michael" == Michael Snoyman
wrote: Michael> For the sqlite backend for persistent, I took direct-sqlite Michael> and modified it slightly. I have a long history of using the Michael> sqlite3 C API, so the API felt very familiar to me.
So, it seems you're satisfiew with direct-sqlite?
What is missing in 1st package (Galois bindings)?
I didn't investigate it, I would imagine it's pretty complete if Galois wrote it. I stuck with direct-sqlite just because it was so incredibly simple (single file, ~15 functions).
btw, after some research, I've concluded that NOSQL (Redis, MongoDB) are not good solutions in our use-case since we want to have extensive querying support and using sqlite3 with SQL seems better option.
That's why I'm sticking with SQL for my current project.
Michael> If I'm not mistaken, direct-sqlite does not build as-is on
Michael> hackage because it's missing a reference to the C library.
Hmm...you're right.
Apparently Archlinux package built OK; but loading it into ghci gives:
ghc: /usr/lib/direct-sqlite-1.0/ghc-6.12.1/HSdirect-sqlite-1.0.o: unknown symbol `sqlite3_column_blob'
Thank you.
Michael> However, if you take my approach and just include the code in Michael> your library, you can fix that easily enough.
It looks it's the problem with package's cabal file...
True, it's a very simple fix. In fact, you can just include the sqlite amalgamation file with the code and not worry about library dependencies.
Michael

I am the author of direct-sqlite, and I thank you for the bug report.
I'll be fixing this as soon as I'm able. It's always nice to hear
about people using my code!
On Wed, Jul 21, 2010 at 2:10 AM, Michael Snoyman
On Wed, Jul 21, 2010 at 8:59 AM, Gour
wrote: On Wed, 21 Jul 2010 08:06:49 +0300
>> "Michael" == Michael Snoyman
wrote: Michael> For the sqlite backend for persistent, I took direct-sqlite Michael> and modified it slightly. I have a long history of using the Michael> sqlite3 C API, so the API felt very familiar to me.
So, it seems you're satisfiew with direct-sqlite?
What is missing in 1st package (Galois bindings)?
I didn't investigate it, I would imagine it's pretty complete if Galois wrote it. I stuck with direct-sqlite just because it was so incredibly simple (single file, ~15 functions).
btw, after some research, I've concluded that NOSQL (Redis, MongoDB) are not good solutions in our use-case since we want to have extensive querying support and using sqlite3 with SQL seems better option.
That's why I'm sticking with SQL for my current project.
Michael> If I'm not mistaken, direct-sqlite does not build as-is on Michael> hackage because it's missing a reference to the C library.
Hmm...you're right.
Apparently Archlinux package built OK; but loading it into ghci gives:
ghc: /usr/lib/direct-sqlite-1.0/ghc-6.12.1/HSdirect-sqlite-1.0.o: unknown symbol `sqlite3_column_blob'
Thank you.
Michael> However, if you take my approach and just include the code in Michael> your library, you can fix that easily enough.
It looks it's the problem with package's cabal file...
True, it's a very simple fix. In fact, you can just include the sqlite amalgamation file with the code and not worry about library dependencies. Michael _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Dan Knapp "An infallible method of conciliating a tiger is to allow oneself to be devoured." (Konrad Adenauer)

Sorry I didn't send it earlier, it must have slipped my mind.
On Sun, Jul 25, 2010 at 3:07 AM, Dan Knapp
I am the author of direct-sqlite, and I thank you for the bug report. I'll be fixing this as soon as I'm able. It's always nice to hear about people using my code!
On Wed, Jul 21, 2010 at 2:10 AM, Michael Snoyman
wrote: On Wed, Jul 21, 2010 at 8:59 AM, Gour
wrote: On Wed, 21 Jul 2010 08:06:49 +0300
>>> "Michael" == Michael Snoyman
wrote: Michael> For the sqlite backend for persistent, I took direct-sqlite Michael> and modified it slightly. I have a long history of using the Michael> sqlite3 C API, so the API felt very familiar to me.
So, it seems you're satisfiew with direct-sqlite?
What is missing in 1st package (Galois bindings)?
I didn't investigate it, I would imagine it's pretty complete if Galois wrote it. I stuck with direct-sqlite just because it was so incredibly simple (single file, ~15 functions).
btw, after some research, I've concluded that NOSQL (Redis, MongoDB) are not good solutions in our use-case since we want to have extensive querying support and using sqlite3 with SQL seems better option.
That's why I'm sticking with SQL for my current project.
Michael> If I'm not mistaken, direct-sqlite does not build as-is on Michael> hackage because it's missing a reference to the C library.
Hmm...you're right.
Apparently Archlinux package built OK; but loading it into ghci gives:
ghc: /usr/lib/direct-sqlite-1.0/ghc-6.12.1/HSdirect-sqlite-1.0.o: unknown symbol `sqlite3_column_blob'
Thank you.
Michael> However, if you take my approach and just include the code in Michael> your library, you can fix that easily enough.
It looks it's the problem with package's cabal file...
True, it's a very simple fix. In fact, you can just include the sqlite amalgamation file with the code and not worry about library dependencies. Michael _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Dan Knapp "An infallible method of conciliating a tiger is to allow oneself to be devoured." (Konrad Adenauer) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (3)
-
Dan Knapp
-
Gour
-
Michael Snoyman