I wasn't suggesting that you use sqlite3_exec. On the contrary I would
counsel you not to. I just suggested that you look to see how it
implements callbacks and that you implement a callback to handle each
row. Then the logic of your interface is elegant.
If you are creating a language interface, you have assumed
responsibility to make it work seamlessly and flawlessly.
You will find on reflection that the Sqlite API is simple and elegant
and will let you craft your interface provided you design it to suit
Sqlite, not have a preconceived notion and then be unable to make the
connection.
I understood quite well what you are trying to achieve and suggested
that you rethink your strategy.
I suggest that you also look carefully at the manifest typing
implemented in Sqlite. If your language is strongly typed you will have
some design issues to address.
Wesley W. Terpstra wrote:
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]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
