Closed
Bug 492379
Opened 16 years ago
Closed 14 years ago
Need a script to allow nightlies downgrade with bad views
Categories
(Toolkit :: Places, defect)
Toolkit
Places
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: mak, Assigned: ddahl)
References
Details
Attachments
(1 file, 2 obsolete files)
(deleted),
text/plain
|
Details |
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.
Assignee | ||
Comment 1•16 years ago
|
||
So the query in this script should remove the last_visit_date col from moz_places and the corresponding index?
Reporter | ||
Comment 2•16 years ago
|
||
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)
Assignee | ||
Comment 3•16 years ago
|
||
do we have existing code for checking build versions?
Reporter | ||
Comment 4•16 years ago
|
||
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.
Comment 5•16 years ago
|
||
We should just check nsPIPlacesDatabase::DBConnection::schemaVersion, no?
Assignee | ||
Comment 7•16 years ago
|
||
Just curious if I am approaching this correctly/ untested. (building with the patch as I write this)
Attachment #376814 -
Flags: review?(mak77)
Reporter | ||
Comment 8•16 years ago
|
||
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)
Reporter | ||
Comment 9•16 years ago
|
||
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)
Comment 10•16 years ago
|
||
(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.
Comment 11•16 years ago
|
||
(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.
Comment 12•16 years ago
|
||
(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.
Assignee | ||
Comment 13•16 years ago
|
||
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?
Comment 14•16 years ago
|
||
Use mozIStorageConnection::schemaVersion instead of raw SQL.
Assignee | ||
Comment 15•16 years ago
|
||
Stuck on a syntax error. About to start testing with a real db.
Attachment #376814 -
Attachment is obsolete: true
Assignee | ||
Comment 16•16 years ago
|
||
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)
Updated•16 years ago
|
Attachment #379002 -
Attachment is patch: false
Comment 17•16 years ago
|
||
which query fails exactly?
Comment 18•16 years ago
|
||
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)
Reporter | ||
Comment 19•14 years ago
|
||
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: 14 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•