On 3/2/2016 9:41 PM, Andy Bradford wrote:
Thus said Ross Berteig on Wed, 02 Mar 2016 19:24:55 -0800:
Yes, apparently it has. In isValidLocalDb() in src/db.c ca. line 1099,
there are two if blocks that test for some feature of the local db
schema, and to the needed ALTER TABLE commands to fix things up.
The ALTER TABLE commands there are not the kind mentioned here:
https://www.sqlite.org/lang_altertable.html#otheralter
I could be wrong, but I think ALTER TABLE for changing a PRIMARY KEY is
much more involved than what isValidLocalDb() currently does.
Looks like you are right that SQLite doesn't support using ALTER TABLE
to directly change a primary key. Darn.
Aside from the schema update, which I think does have a fairly
painless fix, I'm fine with getting this fixed.
When you say painless do you mean ``cd /new/checkout && fossil open
/repo.fossil'' or do you mean finding the magic ALTER TABLE sauce for
altering a PRIMARY KEY?
I assumed that ALTER TABLE could move the primary key in one statement
or so. Apparently it is more work than that. The recipe doesn't look too
bad, though, but someone who really speaks SQL and knows the subtleties
of SQLite might want to weigh in.
BEGIN TRANSACTION;
ALTER TABLE stashfile RENAME TO oldstashfile;
CREATE TABLE stashfile ...; --The new schema with new primary key.
INSERT INTO stashfile SELECT * FROM oldstashfile;
DROP TABLE oldstashfile;
COMMIT;
Assuming that the existing stashed data will comply with the new schema
constraints, I think that it could be executed in one go.
But I am far from expert on SQL and SQLite, so I'm hoping that one of
our team who is an expert will chime in on what the right thing to do is.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
