Re: [Chicken-users] SQLite3 bindings for CHICKEN 4

[Thomas Chust]

2009/8/5 Peter Bex <address@hidden>:
> [...]
>> Could you elaborate which parts of the
>> sql-de-lite API seem more schemely to you?
>
> sqlite3 is more OO-like and has many operations which are purely invoked
> for their side-effects (returning #<void>), whereas sql-de-lite seems
> more FP-like and minimal.
> [...]

Hello,

as far as I can see, both sql-de-lite and my sqlite3 egg offer the
same low level, side-effecting procedures plus the same type of
functional abstractions -- the only notable difference is that
sql-de-lite doesn't suffix all the operations called purely for
side-effects with an exclamation mark (compare, for example, step in
sql-de-lite with step! in my sqlite3 egg), so the API looks more
functional to a Scheme programmer at first glance, but really isn't
;-)

Would it help if I modified some of the side-effecting procedures to
return their primary argument to enable method chaining?

> [...]
>> Allowing the database to be
>> closed if statements are still active is necessary when a statement
>> cache is used, but I think it opens a source of hard to find bugs if
>> included in a low level database access layer like sql-de-lite -- the
>> application programmer is still responsible that every statement has
>> finished executing before the database is closed, but will no longer
>> be notified when she fails to do so.
>
> I'm not sure about this.  Could you give an example?

If, for example, you prepare a statement and forget to ever execute
and finalize it, my sqlite3 egg will at least tell you that you have
an unused statement lying around when you try to close the database.
With sql-de-lite, the statement will never be compiled or will just
silently be finalized.

This example may seem contrived, since a functional programming style
should usually prevent this situation from arising. However it can
easily happen in a multithreaded environment and the error reporting
from the database has at least once saved me from introducing stupid
synchronisation bugs there, which are always hard to track down.

Of course, having a global statement cache makes multithreaded
programming using sql-de-lite nearly impossible anyway. Opening
multiple database connections to the same database from inside the
same operating system thread, like sql-de-lite claims it is possible,
only helps if you are lucky either, since it may cause locking
problems.

cu,
Thomas


-- 
When C++ is your hammer, every problem looks like your thumb.