On Wed, Jul 21, 2010 at 2:10 AM, Michael Snoyman <
michael@snoyman.com> wrote:
>
>
> On Wed, Jul 21, 2010 at 8:59 AM, Gour <
gour@gour-nitai.com> wrote:
>>
>> On Wed, 21 Jul 2010 08:06:49 +0300
>> >>>>>> "Michael" == Michael Snoyman <
michael@snoyman.com> 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