On Feb 12, 2007, at 3:22 PM, John Stanton wrote:
Look at how Sqlite implements callbacks in sqlite3_exec to discover
a way to implement your language.
I had already looked at it. I will be using the prepare_v2/bind/step/
reset/.../finalize interface instead. The exec interface is too
simplified. Incidentally, SML is not my language. It has been
standardized since 1997.
Doing that will ensure that the transactions are atomic and that
database integrity is maintained.
How are ACID properties in any way my responsibility? They are SQLite's.
No offence, but I think you've completely missed my point.
My questions had to do with how the SQLite interface behaves in cases
that are undocumented in the C API (which I have read completely,
several times). I need to know exactly which sequence of method calls
are allowed, in order to bind the library in such a way that the type
checker in SML will ensure only correct use. SML type-safety is much
stronger than in C. If a program compiles, it is guaranteed not to
segfault/etc. Therefore, binding a C library must be done carefully
to preserve this guarantee.
The problem I was talking about comes from (what I see as) a
deficiency in the SQLite3 API. That is, the compiled query and it's
state are associated with the same opaque data structure. Switching
to using exec will not solve this.
It looks like I'll have to do a SQLite3 source dive to see how hard
it would be to separate state from statements. If I can't do this,
then I will have to settle for a less elegant binding, without
precompiled queries.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
