Change models and write database migrations

The migration first renames location_id to legacy_location_id and then populates a new location_id with the HLDS IDs. I temporarily disabled the DROP COLUMN legacy_location_id in the migration, and ran these queries:

> SELECT id, legacy_location_id, location_id FROM `order` WHERE `order`.location_id IS NULL
  AND `order`.legacy_location_id IS NOT NULL;
Empty set
> SELECT id, legacy_location_id, location_id FROM `order` WHERE `order`.location_id IS NULL;
+-----+--------------------+-------------+
| id  | legacy_location_id | location_id |
+-----+--------------------+-------------+
|  17 |               NULL | NULL        |
|  39 |               NULL | NULL        |
..snip (all same pattern)
24 rows in set

The second query is to visually confirm the findings of the first.

We conclude that indeed, there are no orders where we are losing information about which location the order was for. Good!

Check that order_items that had a product, have a dish now

We do a similar thing for order_items and their products (old term) / dishes (new term)

> SELECT id, legacy_product_id, dish_name FROM `order_item` WHERE `order_item`.dish_name IS NULL
  AND `order_item`.legacy_product_id IS NOT NULL;
Empty set
> SELECT id, legacy_product_id, dish_name FROM `order_item` WHERE `order_item`.dish_name IS NULL;
+------+-------------------+-----------+
| id   | legacy_product_id | dish_name |
+------+-------------------+-----------+
|   11 |              NULL | NULL      |
|   12 |              NULL | NULL      |
..snip (all same pattern)
152 rows in set

All good!

The dish IDs will have to be checked in the future, when #23 is done. The same query can be used, just change dish_name to dish_id.

To ensure that no data is lost, I did the following. ## Check that orders that had a location, still do The migration first renames *location_id* to *legacy_location_id* and then populates a new *location_id* with the HLDS IDs. I temporarily disabled the *DROP COLUMN legacy_location_id* in the migration, and ran these queries: ``` > SELECT id, legacy_location_id, location_id FROM `order` WHERE `order`.location_id IS NULL AND `order`.legacy_location_id IS NOT NULL; Empty set > SELECT id, legacy_location_id, location_id FROM `order` WHERE `order`.location_id IS NULL; +-----+--------------------+-------------+ | id | legacy_location_id | location_id | +-----+--------------------+-------------+ | 17 | NULL | NULL | | 39 | NULL | NULL | ..snip (all same pattern) 24 rows in set ``` The second query is to visually confirm the findings of the first. We conclude that indeed, there are no orders where we are losing information about which location the order was for. Good! ## Check that order_items that had a product, have a dish now We do a similar thing for *order_items* and their products (old term) / dishes (new term) ``` > SELECT id, legacy_product_id, dish_name FROM `order_item` WHERE `order_item`.dish_name IS NULL AND `order_item`.legacy_product_id IS NOT NULL; Empty set > SELECT id, legacy_product_id, dish_name FROM `order_item` WHERE `order_item`.dish_name IS NULL; +------+-------------------+-----------+ | id | legacy_product_id | dish_name | +------+-------------------+-----------+ | 11 | NULL | NULL | | 12 | NULL | NULL | ..snip (all same pattern) 152 rows in set ``` All good! The dish IDs will have to be checked in the future, when #23 is done. The same query can be used, just change *dish_name* to *dish_id*.

midgard commented

2020-01-26 23:40:12 +01:00

(Migrated from git.zeus.gent)

mentioned in issue #23

midgard commented

2020-01-26 23:41:11 +01:00

(Migrated from git.zeus.gent)

Done in b1d0c3e00466309c6d940410759619b3ffe214d8!

midgard commented

2020-01-26 23:41:12 +01:00

(Migrated from git.zeus.gent)

closed

Change models and write database migrations #3

Check that orders that had a location, still do

Check that order_items that had a product, have a dish now