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: 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




reply via email to

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