Closed
Bug 881486
Opened 12 years ago
Closed 12 years ago
Automatically created tables vs. auth.sql_to_user.sql_migration.txt
Categories
(Cloud Services :: Server: Core, defect)
Cloud Services
Server: Core
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: u422471, Unassigned)
Details
Attachments
(1 file)
1.51 KB,
patch
|
telliott
:
review+
|
Details | Diff | Splinter Review |
Hi,
just noticed that there is a big difference between the automatically created tables in an empty database and the migrations/auth.sql_to_user.sql_migration.txt migration instructions:
auth.sql_to_user.sql_migration.txt:
username varbinary(32) not null
password varbinary(128)
accountStatus int(11) default 1
mailVerified int(11) default 0
automatically created tables:
username varchar(32) not null
password varchar(128)
accountStatus int(11)
mailVerified int(11)
It could be useful to modify one of the above to match the correct ones which should be used.
Comment 1•12 years ago
|
||
Yikes. Here's a fix to what I think the right setup should be.
Attachment #760770 -
Flags: review?(telliott)
Comment 2•12 years ago
|
||
Comment on attachment 760770 [details] [diff] [review]
patch to fix table declarations
I don't actually think varbinary/varchar makes any difference in this case, since we control the charset of the password, and they should be the same. Doesn't hurt to fix it.
The server_default versus default thing is kind of clownshoes. ORMs :P
Attachment #760770 -
Flags: review?(telliott) → review+
Comment 3•12 years ago
|
||
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•