Closed Bug 492379 Opened 15 years ago Closed 13 years ago

Need a script to allow nightlies downgrade with bad views

Categories

(Toolkit :: Places, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mak, Assigned: ddahl)

References

Details

Attachments

(1 file, 2 obsolete files)

bug 491954 fixed a flaw in our views design, if we add a column to moz_places or moz_historyvisits, a downgrade to a 3.1/3.5 nightly BEFORE bug 491954 won't be possible since our views do union with SELECT *, so are trying to union tables with different sizes.

We need a small script to fix dbs for nightly testers/QA, that will downgrade the table to an usable state.
So the query in this script should remove the last_visit_date col from moz_places and the corresponding index?
that's what it should do, if possible would be cool to check build version and limit the change to known bad versions (from first build with temp tables to today's nightly included)
do we have existing code for checking build versions?
you can probably parse the user agent.
Notice if the above happens Places won't be able to start, you'll probably need to create your own connection to the db.
We should just check nsPIPlacesDatabase::DBConnection::schemaVersion, no?
we don't even know if we have a db connection, see comment 4.
Just curious if I am approaching this correctly/ untested. (building with the patch as I write this)
Attachment #376814 - Flags: review?(mak77)
Comment on attachment 376814 [details] [diff] [review]
WIP - untested, how is the approach?


>+  if (parseInt(_d) < 20090512){
>+    dump("This verison of the Places database does not need to be downgraded");
>+  }
>+  else {
>+    dump("downgrade required");
>+  }

we need to downgrade when

schema version == 9
and
build id < tomorrow AND build id > (first version with temp tables, looks like we pushed them on 2008-11-03, see bug 450290)

>+
>+  var file =
>+    Cc["@mozilla.org/file/directory_service;1"].
>+    getService(Ci.nsIProperties).
>+    get("ProfD", Ci.nsIFile);
>+
>+  if (Ci.nsPIPlacesDatabase) {
>+    var shared = true;
>+    var conn =
>+      Cc["@mozilla.org/browser/nav-history-service;1"].
>+      getService(Ci.nsPIPlacesDatabase).
>+      DBConnection;

i think this will throw when you'll try to get history service if it can't initialize.
plus you should check that DBConnection is ready (see storage docs for the correct property name)


>+  // queries in order to be executed:
>+  // create tmp table
>+  var queryCreateTmpMozPlaces = mozPlacesCreateTable("moz_places_script_tmp");
>+  // insert real data into tmp table
>+  var queryInsertTmp = "INSERT INTO moz_places_script_tmp SELECT id, url, title, rev_host, visit_count, hidden, typed, favicon_id, frecency FROM moz_places";

put column names in a MOZ_PLACES_COLUMNS const, should make this more readable.

>+  // drop the index:
>+  var queryDropIndex = "DROP INDEX IF EXISTS moz_places.moz_places_lastvisitdateindex";
>+  // drop the 'real' table
>+  var queryDropTable = "DROP TABLE moz_places";

If you drop the table i think indexes will be dropped with it.
So you'll have to recreate all the indexes on the new table.

I was thinking that you can probably rename moz_places table and copy to the new one, instead of copying all contents 2 times, should be faster.


please add a HUGE warning/atyourownrisk/backup disclaimer :)
Attachment #376814 - Flags: review?(mak77)
notice i have to push an additional patch to allow downgrade so date will probably be tomorrow or wednesday. take a look at push times.

also bug 488966 has an unbitrot patch you can compile to test your script, and in general our migration to 3.0.x (should work after that patch), or to 3.1/.5 (should fail after that patch unless it has the additional patch i'm pushing on bug 491954)
Blocks: 493291
(In reply to comment #4)
> you can probably parse the user agent.

Not sure this is a good idea.  Some of us run with spoofed UA strings.
(In reply to comment #10)
> Not sure this is a good idea.  Some of us run with spoofed UA strings.
We can't optimize for everyone.  You'll just have to reset the user agent if you need to use this script then.
(In reply to comment #10)
> (In reply to comment #4)
> > you can probably parse the user agent.
> 
> Not sure this is a good idea.  Some of us run with spoofed UA strings.

as far as i read the patch correctly

+  var _userAgent = userAgent.split(" ");
+  _userAgent = _userAgent[7];
+  var _d = _userAgent.split("/")[1];
+
+  if (parseInt(_d) < 20090512){

it's the build date string/ID, not the customizable agent field itself that's getting checked - this should be "safe" in any cases.
This appears to get the schema version - I asusme the downgrade should also set the schema version back to "8"? 

var stmt = conn.createStatement("PRAGMA user_version");
  while(stmt.executeStep()){
    var schemaVersion = stmt.getInt32(0);
  }

According to SQLite docs you just do "PRAGMA user_version = 8" to set it. Correct?
Use mozIStorageConnection::schemaVersion instead of raw SQL.
Attached file WIP 2 - just posting to save my work. (obsolete) —
Stuck on a syntax error. About to start testing with a real db.
Attachment #376814 - Attachment is obsolete: true
Seems like JS console does not support JS 1.7 / 1.8 ??? This caused no end of grief. This runs and raises exceptions when creating statements in mozStorage. (Still not working, but close)
Attachment #378471 - Attachment is obsolete: true
Attachment #379002 - Flags: review?(sdwilsh)
Attachment #379002 - Attachment is patch: false
which query fails exactly?
Comment on attachment 379002 [details]
WIP 3 - JS console reports a syntax error. JS shell everything works.

clearing request until comment 17 is answered.
Attachment #379002 - Flags: review?(sdwilsh)
I'd say this is of poor value today. Pursuing bug 431274 to drop and rebuild database is a better strategy.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.