monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Descriptors do make a difference 8-O


From: Derek Scherger
Subject: Re: [Monotone-devel] Descriptors do make a difference 8-O
Date: Mon, 23 May 2005 10:10:54 -0600
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050403)

Nathaniel Smith wrote:
>>static int 
>>dump_table_cb(void *data, int n, char **vals, char **cols)
>>{
>>[...]
>>      sqlite3_exec_printf(dump->sql, "SELECT * FROM '%q'", 
>>                         dump_row_cb, data, NULL, vals[0]);
>>[...]
> 
> Why does this code still call sqlite3_exec_printf?  If it were
> changed, then sqlite3_exec_printf and sqlite3_exec_vprintf could both
> be removed.

At a glance I'd say it was because the prepared statement machinery
doesn't support callbacks in the same way that exec does. Looking at it
now it seems easy enough to remove the printf stuff, so I'll have a go
at that, should be done shortly.

>>+  oss << "sqlite errcode=" << errcode << " " << errmsg;
> 
> This doesn't seem like a very friendly error message :-).  Surely we
> can log the number and say something like "sqlite error: " instead for
> the user-visible part?

I'll change the format to "sqlite error [123]: message" where message is
the decoded string from sqlite3_errmsg. This is pretty close to what we
have in assert_sqlite3_ok in mainline now, except that we're letting
sqlite decode its errors rather than doing it ourselves and we're
including the error number which might help diagnose the odd problem.

>>PS: Nathaniel: How would you tag a column to contain BLOBs in a way that
>>makes schema migration possible?

I wonder if we could include the type of the columns in schema.sql? I
know sqlite doesn't seem to like types, but they do occasinally seem
relevant.

Cheers,
Derek




reply via email to

[Prev in Thread] Current Thread [Next in Thread]