veniasilente/veekun_pokedex
1
0
Fork 0
mirror of https://github.com/veekun/pokedex.git synced 2024-07-03 11:05:49 +00:00
Code Issues Projects Releases Wiki Activity
veekun_pokedex/pokedex/data/csv/pokemon_abilities.csv

779 lines
6.7 KiB
Plaintext
Raw Normal View History

Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
pokemon_id,ability_id,slot
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
1,65,1
2,65,1
3,65,1
4,66,1
5,66,1
6,66,1
7,67,1
8,67,1
9,67,1
10,19,1
11,61,1
12,14,1
13,19,1
14,61,1
15,68,1
16,51,1
16,77,2
17,51,1
17,77,2
18,51,1
18,77,2
19,50,1
19,62,2
20,50,1
20,62,2
21,51,1
22,51,1
23,22,1
23,61,2
24,22,1
24,61,2
25,9,1
26,9,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
27,8,1
28,8,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
29,38,1
29,79,2
30,38,1
30,79,2
31,38,1
31,79,2
32,38,1
32,79,2
33,38,1
33,79,2
34,38,1
34,79,2
35,56,1
35,98,2
36,56,1
36,98,2
37,18,1
38,18,1
39,56,1
40,56,1
41,39,1
42,39,1
43,34,1
44,34,1
45,34,1
46,27,1
46,87,2
47,27,1
47,87,2
48,14,1
48,110,2
49,19,1
49,110,2
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
50,8,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
50,71,2
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
51,8,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
51,71,2
52,53,1
52,101,2
53,7,1
53,101,2
54,6,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
54,13,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
55,6,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
55,13,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
56,72,1
56,83,2
57,72,1
57,83,2
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
58,18,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
58,22,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
59,18,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
59,22,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
60,6,1
60,11,2
61,6,1
61,11,2
62,6,1
62,11,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
63,28,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
63,39,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
64,28,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
64,39,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
65,28,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
65,39,2
66,62,1
66,99,2
67,62,1
67,99,2
68,62,1
68,99,2
69,34,1
70,34,1
71,34,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
72,29,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
72,64,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
73,29,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
73,64,2
74,5,1
74,69,2
75,5,1
75,69,2
76,5,1
76,69,2
77,18,1
77,50,2
78,18,1
78,50,2
79,12,1
79,20,2
80,12,1
80,20,2
81,5,1
81,42,2
82,5,1
82,42,2
83,39,1
83,51,2
84,48,1
84,50,2
85,48,1
85,50,2
86,47,1
86,93,2
87,47,1
87,93,2
88,1,1
88,60,2
89,1,1
89,60,2
90,75,1
90,92,2
91,75,1
91,92,2
92,26,1
93,26,1
94,26,1
95,5,1
95,69,2
96,15,1
96,108,2
97,15,1
97,108,2
98,52,1
98,75,2
99,52,1
99,75,2
100,9,1
100,43,2
101,9,1
101,43,2
102,34,1
103,34,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
104,31,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
104,69,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
105,31,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
105,69,2
106,7,1
106,120,2
107,51,1
107,89,2
108,12,1
108,20,2
109,26,1
110,26,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
111,31,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
111,69,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
112,31,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
112,69,2
113,30,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
113,32,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
114,34,1
114,102,2
115,48,1
115,113,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
116,33,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
116,97,2
117,38,1
117,97,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
118,33,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
118,41,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
119,33,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
119,41,2
120,30,1
120,35,2
121,30,1
121,35,2
122,43,1
122,111,2
123,68,1
123,101,2
124,12,1
124,108,2
125,9,1
126,49,1
127,52,1
127,104,2
128,22,1
128,83,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
129,33,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
130,22,1
131,11,1
131,75,2
132,7,1
133,50,1
133,91,2
134,11,1
134,11,2
135,10,1
135,10,2
136,18,1
136,18,2
137,36,1
137,88,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
138,33,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
138,75,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
139,33,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
139,75,2
140,4,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
140,33,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
141,4,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
141,33,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
142,46,1
142,69,2
143,17,1
143,47,2
144,46,1
145,46,1
146,46,1
147,61,1
148,61,1
149,39,1
150,46,1
151,28,1
152,65,1
153,65,1
154,65,1
155,66,1
156,66,1
157,66,1
158,67,1
159,67,1
160,67,1
161,50,1
161,51,2
162,50,1
162,51,2
163,15,1
163,51,2
164,15,1
164,51,2
165,48,1
165,68,2
166,48,1
166,68,2
167,15,1
167,68,2
168,15,1
168,68,2
169,39,1
170,10,1
170,35,2
171,10,1
171,35,2
172,9,1
173,56,1
173,98,2
174,56,1
175,32,1
175,55,2
176,32,1
176,55,2
177,28,1
177,48,2
178,28,1
178,48,2
179,9,1
180,9,1
181,9,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
182,34,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
183,37,1
183,47,2
184,37,1
184,47,2
185,5,1
185,69,2
186,6,1
186,11,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
187,34,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
187,102,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
188,34,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
188,102,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
189,34,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
189,102,2
190,50,1
190,53,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
191,34,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
191,94,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
192,34,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
192,94,2
193,3,1
193,14,2
194,6,1
194,11,2
195,6,1
195,11,2
196,28,1
196,28,2
197,28,1
197,28,2
198,15,1
198,105,2
199,12,1
199,20,2
200,26,1
201,26,1
202,23,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
203,39,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
203,48,2
204,5,1
205,5,1
206,32,1
206,50,2
207,8,1
207,52,2
208,5,1
208,69,2
209,22,1
209,50,2
210,22,1
210,95,2
211,33,1
211,38,2
212,68,1
212,101,2
213,5,1
213,82,2
214,62,1
214,68,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
215,39,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
215,51,2
216,53,1
216,95,2
217,62,1
217,95,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
218,40,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
218,49,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
219,40,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
219,49,2
220,12,1
220,81,2
221,12,1
221,81,2
222,30,1
222,55,2
223,55,1
223,97,2
224,21,1
224,97,2
225,55,1
225,72,2
226,11,1
226,33,2
227,5,1
227,51,2
228,18,1
228,48,2
229,18,1
229,48,2
230,33,1
230,97,2
231,53,1
232,5,1
233,36,1
233,88,2
234,22,1
234,119,2
235,20,1
235,101,2
236,62,1
236,80,2
237,22,1
237,101,2
238,12,1
238,108,2
239,9,1
240,49,1
241,47,1
241,113,2
242,30,1
242,32,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
243,46,1
244,46,1
245,46,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
246,62,1
247,61,1
248,45,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
249,46,1
250,46,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
251,30,1
252,65,1
253,65,1
254,65,1
255,66,1
256,66,1
257,66,1
258,67,1
259,67,1
260,67,1
261,50,1
261,95,2
262,22,1
262,95,2
263,53,1
263,82,2
264,53,1
264,82,2
265,19,1
266,61,1
267,68,1
268,61,1
269,19,1
270,33,1
270,44,2
271,33,1
271,44,2
272,33,1
272,44,2
273,34,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
273,48,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
274,34,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
274,48,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
275,34,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
275,48,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
276,62,1
277,62,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
278,51,1
279,51,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
280,28,1
280,36,2
281,28,1
281,36,2
282,28,1
282,36,2
283,33,1
284,22,1
285,27,1
285,90,2
286,27,1
286,90,2
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
287,54,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
288,72,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
289,54,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
290,14,1
291,3,1
292,25,1
293,43,1
294,43,1
295,43,1
296,47,1
296,62,2
297,47,1
297,62,2
298,37,1
298,47,2
299,5,1
299,42,2
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
300,56,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
300,96,2
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
301,56,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
301,96,2
302,51,1
302,100,2
303,22,1
303,52,2
304,5,1
304,69,2
305,5,1
305,69,2
306,5,1
306,69,2
307,74,1
308,74,1
309,9,1
309,31,2
310,9,1
310,31,2
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
311,57,1
312,58,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
313,35,1
313,68,2
314,12,1
314,110,2
315,30,1
315,38,2
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
316,60,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
316,64,2
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
317,60,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
317,64,2
318,24,1
319,24,1
320,12,1
320,41,2
321,12,1
321,41,2
322,12,1
322,86,2
323,40,1
323,116,2
324,73,1
325,20,1
325,47,2
326,20,1
326,47,2
327,20,1
327,77,2
328,52,1
328,71,2
329,26,1
329,26,2
330,26,1
330,26,2
331,8,1
332,8,1
333,30,1
334,30,1
335,17,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
336,61,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
337,26,1
338,26,1
339,12,1
339,107,2
340,12,1
340,107,2
341,52,1
341,75,2
342,52,1
342,75,2
343,26,1
344,26,1
345,21,1
346,21,1
347,4,1
348,4,1
349,33,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
350,63,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
351,59,1
352,16,1
353,15,1
353,119,2
354,15,1
354,119,2
355,26,1
356,46,1
357,34,1
357,94,2
358,26,1
359,46,1
359,105,2
360,23,1
361,39,1
361,115,2
362,39,1
362,115,2
363,47,1
363,115,2
364,47,1
364,115,2
365,47,1
365,115,2
366,75,1
367,33,1
368,33,1
369,33,1
369,69,2
370,33,1
371,69,1
372,69,1
373,22,1
374,29,1
375,29,1
376,29,1
377,29,1
378,29,1
379,29,1
380,26,1
381,26,1
382,2,1
383,70,1
384,76,1
385,32,1
386,46,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
387,65,1
388,65,1
389,65,1
390,66,1
391,66,1
392,66,1
393,67,1
394,67,1
395,67,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
396,51,1
397,22,1
398,22,1
399,86,1
399,109,2
400,86,1
400,109,2
401,61,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
402,68,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
403,22,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
403,79,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
404,22,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
404,79,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
405,22,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
405,79,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
406,30,1
406,38,2
407,30,1
407,38,2
408,104,1
409,104,1
410,5,1
411,5,1
412,61,1
413,107,1
414,68,1
415,118,1
416,46,1
417,50,1
417,53,2
418,33,1
419,33,1
420,34,1
421,122,1
422,60,1
422,114,2
423,60,1
423,114,2
424,53,1
424,101,2
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
425,84,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
425,106,2
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
426,84,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
426,106,2
427,50,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
427,103,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
428,56,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
428,103,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
429,26,1
430,15,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
430,105,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
431,7,1
431,20,2
432,20,1
432,47,2
433,26,1
434,1,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
434,106,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
435,1,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
435,106,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
436,26,1
436,85,2
437,26,1
437,85,2
438,5,1
438,69,2
439,43,1
439,111,2
440,30,1
440,32,2
441,51,1
441,77,2
442,46,1
443,8,1
444,8,1
445,8,1
446,47,1
446,53,2
447,39,1
447,80,2
448,39,1
448,80,2
449,45,1
450,45,1
451,4,1
451,97,2
452,4,1
452,97,2
453,87,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
453,107,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
454,87,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
454,107,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
455,26,1
456,33,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
456,114,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
457,33,1
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
457,114,2
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
458,11,1
458,33,2
Initial commit, with much of the data imported. Includes a wrapper script 'pokedex' that can, so far, read data from a db and spit out CSVs or deploy CSVs to a db.
2009-02-05 08:05:42 +00:00
459,117,1
460,117,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
461,46,1
461,46,2
462,5,1
462,42,2
463,12,1
463,20,2
464,31,1
464,116,2
465,34,1
465,102,2
466,78,1
467,49,1
468,32,1
468,55,2
469,3,1
469,110,2
470,102,1
470,102,2
471,81,1
471,81,2
472,8,1
472,52,2
473,12,1
473,81,2
474,88,1
474,91,2
475,80,1
475,80,2
476,5,1
476,42,2
477,46,1
478,81,1
478,81,2
479,26,1
480,26,1
481,26,1
482,26,1
483,46,1
484,46,1
485,18,1
486,112,1
487,46,1
488,26,1
489,93,1
490,93,1
Reordered some rows in mapping tables. This does NOT actually change the data at all! These tables were apparently created with no key defined, so the rows were in arbitrary order -- but when I created and populated the tables in MySQL on nyarumaa, the keys were defined correctly, and InnoDB ordered them by key. This is about what should happen anyway and the discrepancy adds clutter when dumping corrections, so I'm just committing the new order.
2009-05-01 13:29:19 +00:00
491,123,1
Fixed csvexport to write in primary key order. Good news: This no longer relies on InnoDB's default row order. Bad news: InnoDB in MySQL 5.0 has a bug where it will sort rows physically according to a secondary index, if there's a composite primary key and a single-column index and the phase of the moon is right. So a couple tables have been, once again, reordered -- but correctly this time. Good news: This bug will no longer fuck me up!
2009-07-27 05:19:27 +00:00
492,30,1
493,121,1
496,46,1
497,46,1
498,46,1
499,107,1
500,107,1
501,26,1
502,32,1
503,26,1
504,26,1
505,26,1
506,26,1
507,26,1
Reference in a new issue Copy permalink