Closed
Bug 980776
Opened 11 years ago
Closed 11 years ago
Sync1.5 "collections" table has wrong schema
Categories
(Cloud Services :: Operations: Miscellaneous, task, P1)
Cloud Services
Operations: Miscellaneous
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: rfkelly, Unassigned)
References
Details
(Whiteboard: [qa+])
I'm on sync-1-us-east-1.stage.mozaws.net and am getting an IntegrityError when trying to insert a custom collection name into the "collections" table, as shown in Bug 980239 Comment 7. The table schema reported by mysql is:
mysql> describe collections;
+--------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------------+-------------+------+-----+---------+-------+
| userid | int(11) | NO | PRI | NULL | |
| collectionid | smallint(6) | NO | PRI | NULL | |
| name | varchar(32) | NO | | NULL | |
+--------------+-------------+------+-----+---------+-------+
This doesn't match what is expected by the new python codebase:
collections = Table(
"collections",
Column("collectionid", Integer, primary_key=True, nullable=False, autoincrement=True),
Column("name", String(32), nullable=False, unique=True)
)
There should be no "userid" column, and "collectionid" should be an autoincrement primary key. I guess we didn't catch this in the migration from the sync1.1 schema. Bob I'm happy to help edit the schema definition to match here.
James, we need to add a run of the live functional tests to our regularly-schedule test plan, they contain many uses of custom collection names and would surely have turned up this bug a lot sooner.
Reporter | ||
Updated•11 years ago
|
Severity: normal → blocker
Priority: -- → P1
Reporter | ||
Updated•11 years ago
|
Reporter | ||
Comment 1•11 years ago
|
||
Per Bug 980239 this is causing user-facing service problems with third-party sync addons, so I've bumped the priority up as high as it will go.
Reporter | ||
Comment 2•11 years ago
|
||
The good news is, there's no possible way we can have inserted anything into these tables in production, so it should be safe to drop them and re-create with a corrected schema.
Comment 3•11 years ago
|
||
Production schema has been fixed.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Whiteboard: [qa+]
Comment 4•11 years ago
|
||
Cool and here is what I run now with each new deployment to Stage:
./local/bin/python ./syncstorage/tests/functional/test_storage.py --use-token-server <Stage TokenServer>
./local/bin/python ./syncstorage/tests/functional/test_storage.py <Stage Sync Node>#<NODE SECRET>
Nothing yet specific to TokenServer...
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•