[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Descriptors do make a difference 8-O
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] Descriptors do make a difference 8-O |
Date: |
Mon, 23 May 2005 00:47:18 -0700 |
User-agent: |
Mutt/1.5.9i |
On Mon, May 23, 2005 at 09:19:44AM +0200, Christof Petig wrote:
> Nathaniel Smith schrieb:
> > I'm not quite sure what's going on here, but clearly this change makes
> > the code and comment inconsistent. (I guess %-signs are now
> > automatically okay because we no longer go via printf? What if the
> > user does "db execute <something with a ?-sign in it>"? Are we
> > automatically okay because the only place you can put a ?-sign in
> > normal sql is inside ''-quotes, and sqlite won't try to interpret one
> > there?)
>
> db execute <something with a ?-sign in it>
> should give the expected ;-) result : too few arguments for query.
Okay, sounds like we can just delete the comment, then...
> >>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.
>
> Derek did not change this (and I did not think about it that deeply
> since I wanted to maintain the changes as unintrusive as possible).
> Incremental refinement is always possible once the patch is in mainline.
Fair enough. Let's not forget to make this one, though :-).
> >>PS: Nathaniel: How would you tag a column to contain BLOBs in a way that
> >>makes schema migration possible?
> >
> >
> > Not sure what you mean here?
>
> If I had enough time to try making the certs BLOBS, how would you
> represent this change in the schema (so that db migration is possible).
>
> Currently we have
> value not null, -- opaque blob
> signature not null, -- RSA/SHA1 signature of "address@hidden:val]"
>
> how would you change this to reflect the fact that value and signature
> are no longer base64 encoded.
Good question. First solution to come to mind is a bit of a hack:
-- Increment this number when making changes that affect only the
-- format in which data is stored, that wouldn't otherwise cause the
-- schema hash to change.
CREATE TABLE data_version_is_1 (placeholder);
Might be best plan, though.
-- Nathaniel
--
Damn the Solar System. Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
-- Lord Jeffrey