Comments should mostly be composed of sentences. Also next comment below. "Temporary" aside is probably confusing, just "Grab main database." should probably suffice.

On 2008/05/22 23:44:28, Scott.Hess wrote: > Comments should mostly be composed of sentences. Also next comment below. > "Temporary" aside is probably confusing, just "Grab main database." should > probably suffice. Done.

Shouldn't this be ==? No space after = sign in any case :-).

On 2008/05/22 23:44:28, Scott.Hess wrote: > Shouldn't this be ==? No space after = sign in any case :-). Done. See discussion on this below.

sp on first occurrence of transaction. Revise comment to create a sentence.

For Database2, is it even possible to get to this point and not be in a transaction? Given how we're using this function, I'd almost be willing to throw SQLITE_MISUSE or something of the sort if a transaction is not open. I worry about messing with SQLite's transaction machinery.

On 2008/05/22 23:44:28, Scott.Hess wrote: > For Database2, is it even possible to get to this point and not be in a > transaction? Given how we're using this function, I'd almost be willing to > throw SQLITE_MISUSE or something of the sort if a transaction is not open. I > worry about messing with SQLite's transaction machinery. I think this is a very good idea. I am going with it. I modified the code to return SQLITE_MISUSE if called outside of a transaction.

Sorry to be a pain, I'm trying to recall why we're doing this this way. Doing the transaction magic makes me worry that we're going to screw up transactions in some way. Did you try writing code up in database_utils.cc to lift off the authorizer while running PRAGMA user-version? The authorizer's userdata parameter should be able to accomplish this (allowing the authorizer to change results based on state). There's currently no context which can be associated with a particular sqlite3 handle, but OpenSqliteDatabase() is always called in creating a Database object, so such context could reasonably be added. [Note that this thinking is 90% around the transaction magic. If we removed that, then I'd be less worried about doing things this way.]

On 2008/05/22 23:44:28, Scott.Hess wrote: > Sorry to be a pain, I'm trying to recall why we're doing this this way. Doing > the transaction magic makes me worry that we're going to screw up transactions > in some way. Did you try writing code up in database_utils.cc to lift off the > authorizer while running PRAGMA user-version? The authorizer's userdata > parameter should be able to accomplish this (allowing the authorizer to change > results based on state). There's currently no context which can be associated > with a particular sqlite3 handle, but OpenSqliteDatabase() is always called in > creating a Database object, so such context could reasonably be added. > > [Note that this thinking is 90% around the transaction magic. If we removed > that, then I'd be less worried about doing things this way.] If I recall correctly, I started with OP_SetCookie/OP_ReadCookie and traced back to see how a pragma operation would be executed using VDBE interpreter. I can not vouch for a 100% correct traceback, though, so I am perfectly happy with the solution you offered. As for unit tests, unless there are any objectsions, I am putting them into gears/database2/sqlite_user_version_test.cc|h. This should place them next to the code that uses the features.