Update:Remora Migration: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
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