Update:Remora Migration: Difference between revisions
Line 200: | Line 200: | ||
I'm quite open to having someone give some input into this section. | I'm quite open to having someone give some input into this section. | ||
==== A Mapping ==== | |||
Since the migration script is a one-off program (only used once and the thrown away) making a complicated and flexible-intelligent-fuzzy-version-conversion-system isn't necessary. There aren't that many distinct erroneous versions. Manually make a map of Max&MinVer strings to the versions available in the ''appversions'' table. When encountering a mystery version, look it up and proceed. | |||
Should the appversions table be cleaned up first? There doesn't seem to be much rhyme or reason for the use of ".x" ".*" and "+". | |||
Anyone volunteering to help fill in this table? | |||
{| border="1" | |||
!Min&Max!!maps to | |||
|- | |||
|- | |||
|.9||0.9.x | |||
|- | |||
|0.1|| | |||
|- | |||
|0.10|| | |||
|- | |||
|0.10.1||0.10+ | |||
|- | |||
|0.10.1+||0.10+ | |||
|- | |||
|0.10+||0.10+ | |||
|- | |||
|0.11|| | |||
|- | |||
|0.3|| | |||
|- | |||
|0.6|| | |||
|- | |||
|0.7||0.7 | |||
|- | |||
|0.7+||0.7 | |||
|- | |||
|0.8||0.8 | |||
|- | |||
|0.8+||0.8 | |||
|- | |||
|0.80||0.8 | |||
|- | |||
|0.9||0.9.x | |||
|- | |||
|0.9.0+||0.9.x | |||
|- | |||
|0.9.1+||0.9.x | |||
|- | |||
|0.9.2+||0.9.x | |||
|- | |||
|0.9.3||0.9.x | |||
|- | |||
|0.9.3+||0.9.x | |||
|- | |||
|0.9.6||0.9.x | |||
|- | |||
|0.9.x||0.9.x | |||
|- | |||
|0.9+||0.9.x | |||
|- | |||
|00.8||0.8 | |||
|- | |||
|01.6|| | |||
|- | |||
|1.0||1.0 | |||
|- | |||
|1.0.1||1.0.1 | |||
|- | |||
|1.0.2||1.0.2 | |||
|- | |||
|1.0.3||1.0.3 | |||
|- | |||
|1.0.4||1.0.4 | |||
|- | |||
|1.0.5||1.0.5 | |||
|- | |||
|1.0.6||1.0.6 | |||
|- | |||
|1.0.7||1.0.7 | |||
|- | |||
|1.0+||1.0 | |||
|- | |||
|1.0PR||1.0PR | |||
|- | |||
|1.1|| | |||
|- | |||
|1.4|| | |||
|- | |||
|1.4.0|| | |||
|- | |||
|1.4.1|| | |||
|- | |||
|1.5||1.5 | |||
|- | |||
|1.5.0.*||1.5 | |||
|- | |||
|1.5.0.4|| | |||
|- | |||
|1.5*||1.5 | |||
|- | |||
|1.6|| | |||
|- | |||
|1.6a1||1.6.a1 | |||
|- | |||
|2.0||2.0 | |||
|- | |||
|2.0.0.*||2.0 | |||
|- | |||
|2.0.0.a3||2.0a3 | |||
|- | |||
|2.0.0.b1|| | |||
|- | |||
|2.0a1|| | |||
|- | |||
|2.0a2|| | |||
|- | |||
|2.0a3||2.0a3 | |||
|- | |||
|2.0b1|| | |||
|- | |||
|3.0|| | |||
|- | |||
|3.0.0.a1|| | |||
|- | |||
|3.0a1|| | |||
|- | |||
|Deer Park||Deer Park | |||
|} |
Revision as of 03:11, 19 September 2006
The Application Version Problem
The decision to convert the applications_versions.min and applications_versions.max columns from strings into actual foreign keys into the appversions table presents a conversion problem. The original min and max version strings in the old database were not closely policed and do not necessarily map to actual application versions.
How do we make a programmatic mapping from fuzzy application version strings to real ones?
Discussion
Addon #1980 has two versions (both designated as version 1.0, but that is a different problem). The first version of the addon is for Firefox 1.0 through 1.6. Because 1.6 does not exist, migrating that version fails because there is no valid foreign key value for FF1.6. The second version of this addon is for Firefox 1.0 through 1.5.1. Well, that version of Firefox doesn't exist either, so that version fails to migrate.
Many addon version entries have faulty version numbers.
Complicating this issue is the incompleteness of the appversions table. This table is populated by finding the unique entries in the original database's applications table.
Versions from appversions
version from appversions |
---|
0.8 |
0.9.x |
1.0PR |
0.10+ |
0.9.3 |
1.0 |
Deer Park |
0.7 |
1.0.1 |
1.0.2 |
1.0.3 |
1.0.4 |
1.0.5 |
1.0.6 |
1.5b1 |
1.6a1 |
1.0.7 |
1.5b2 |
1.5.0.* |
1.5 |
2.0b1 |
3.0a1 |
1.5.0.4 |
2.0a1 |
2.0a2 |
2.0a3 |
2.0 |
2.0.0.* |
Versions from MinAppVer & MaxAppVer
ersions from MinAppVer & MaxAppVer |
---|
0.8 |
0.9 |
0.7 |
0.6 |
0.7+ |
0.8+ |
0.9.1+ |
0.10 |
0.9.3 |
0.9.0+ |
0.9+ |
1.0 |
0.10+ |
0.9.6 |
0.3 |
.9 |
1.0.1 |
1.0+ |
1.0.4 |
00.8 |
1.5 |
1.4 |
1.0.3 |
1.0.5 |
1.4.0 |
Deer Park |
1.4.1 |
0.1 |
1.0.2 |
1.5* |
1.0.6 |
1.5.0.* |
1.0.7 |
1.5.0.4 |
0.80 |
1.6 |
0.9.x |
1.0PR |
2.0b1 |
2.0a1 |
2.0a2 |
2.0a3 |
0.9.2+ |
0.9.3+ |
0.10.1+ |
0.10.1 |
0.11 |
3.0a1 |
1.1 |
3.0 |
2.0 |
01.6 |
3.0.0.a1 |
1.6a1 |
2.0.0.b1 |
2.0.0.a3 |
2.0.0.* |
The Solution
I'm quite open to having someone give some input into this section.
A Mapping
Since the migration script is a one-off program (only used once and the thrown away) making a complicated and flexible-intelligent-fuzzy-version-conversion-system isn't necessary. There aren't that many distinct erroneous versions. Manually make a map of Max&MinVer strings to the versions available in the appversions table. When encountering a mystery version, look it up and proceed.
Should the appversions table be cleaned up first? There doesn't seem to be much rhyme or reason for the use of ".x" ".*" and "+".
Anyone volunteering to help fill in this table?
Min&Max | maps to |
---|---|
.9 | 0.9.x |
0.1 | |
0.10 | |
0.10.1 | 0.10+ |
0.10.1+ | 0.10+ |
0.10+ | 0.10+ |
0.11 | |
0.3 | |
0.6 | |
0.7 | 0.7 |
0.7+ | 0.7 |
0.8 | 0.8 |
0.8+ | 0.8 |
0.80 | 0.8 |
0.9 | 0.9.x |
0.9.0+ | 0.9.x |
0.9.1+ | 0.9.x |
0.9.2+ | 0.9.x |
0.9.3 | 0.9.x |
0.9.3+ | 0.9.x |
0.9.6 | 0.9.x |
0.9.x | 0.9.x |
0.9+ | 0.9.x |
00.8 | 0.8 |
01.6 | |
1.0 | 1.0 |
1.0.1 | 1.0.1 |
1.0.2 | 1.0.2 |
1.0.3 | 1.0.3 |
1.0.4 | 1.0.4 |
1.0.5 | 1.0.5 |
1.0.6 | 1.0.6 |
1.0.7 | 1.0.7 |
1.0+ | 1.0 |
1.0PR | 1.0PR |
1.1 | |
1.4 | |
1.4.0 | |
1.4.1 | |
1.5 | 1.5 |
1.5.0.* | 1.5 |
1.5.0.4 | |
1.5* | 1.5 |
1.6 | |
1.6a1 | 1.6.a1 |
2.0 | 2.0 |
2.0.0.* | 2.0 |
2.0.0.a3 | 2.0a3 |
2.0.0.b1 | |
2.0a1 | |
2.0a2 | |
2.0a3 | 2.0a3 |
2.0b1 | |
3.0 | |
3.0.0.a1 | |
3.0a1 | |
Deer Park | Deer Park |