Description of problem: We need a script to migrate data from bz db to hwcert db for existing public certs.
We can try to write this script in Python, so that it will be more easy for us to maintain.
(In reply to Huan Zhang from comment #1) > We can try to write this script in Python, so that it will be more easy for > us to maintain. This sentence doesn't include any claims to back it's assertion. (In reply to Tony Fu from comment #0) > Description of problem: > > > We need a script to migrate data from bz db to hwcert db for existing public > certs. This needs to be further clarified, what each script will do, how it will be run how it will be verified, etc. etc. More likely this should be a (set of) management tool(s) that is(are) part of the catalog administration. Also recall that the data will need to be cleaned, there is still rubbish in there like weird all caps version mixed with the normal capitalization and makes that need to be merged. Doing these as a one off script means they cannot be reused to clean up future issue.
(In reply to Rob Landry from comment #2) > (In reply to Huan Zhang from comment #1) > > We can try to write this script in Python, so that it will be more easy for > > us to maintain. > > This sentence doesn't include any claims to back it's assertion. > Please ignore comment #1 :) > > (In reply to Tony Fu from comment #0) > > Description of problem: > > > > > > We need a script to migrate data from bz db to hwcert db for existing public > > certs. > > This needs to be further clarified, what each script will do, how it will be > run how it will be verified, etc. etc. > > > More likely this should be a (set of) management tool(s) that is(are) part > of the catalog administration. Also recall that the data will need to be > cleaned, there is still rubbish in there like weird all caps version mixed > with the normal capitalization and makes that need to be merged. Doing > these as a one off script means they cannot be reused to clean up future > issue. But a simple script is more easy to reach our purpose.
The fields we need for public view are 1. vendor/make/model/category 2. spec url 3. product url 4. support url 5. product 6. version 7.platforms 8. status (it will always display one constant value for public cert, we don't need to worry about it just now) 9. kbase data which is handled by other bugs. So we need 7 data migration script for first 7 fields
(In reply to Tony Fu from comment #5) > The fields we need for public view are > > 1. vendor/make/model/category > 2. spec url > 3. product url > 4. support url > 5. product > 6. version > 7.platforms > 8. status (it will always display one constant value for public cert, we > don't need to worry about it just now) > 9. kbase data which is handled by other bugs. > > So we need 7 data migration script for first 7 fields field 3 and 4 have been in hwcert db, we won't need script to migrate them.
Created attachment 862684 [details] public view db schema We probably should save all new fields as ids instead of strings, but since they will need data cleaning up, we just save a part of fields as ids and leave the rest as what they are in bz db.
Created attachment 863033 [details] sql queries to make db shema changes for public view Just combined all db schema changes sql files, so eng ops can make all required db schema changes in one go. Please note, it doesn't include kbase related changes which is included in other bugs.
Created attachment 863035 [details] script to generate data for two new tables - products and versions
Created attachment 863124 [details] sql queries to make db shema changes for public view
verified on live.