Hazaar Tool: DB migrate snapshot needs to try and detect renamed tables #16

New issue

Closed

opened 2014-03-05 22:44:36 +00:00 by jamie · 4 comments

jamie commented

2014-03-05 22:44:36 +00:00

(Migrated from git.hazaar.io)

I need to have a think about how to handle tables that have been renamed. Currently, renaming a table is detected as a remove and a create action. This works for now and manages to get the schema updated and looking how it should. The problem is, this will cause all the data in the table to be lost, which may not be what we are after.

I see two options here:

Let developers know that renaming a table is bad and will cause the data in the table to be lost (ie: the easy way out).
Try and figure out how to get the snapshot process to detect that a table is being renamed and instead of creating remove and create commands, create a rename command.

I'm inclined to go with option two because hey, this is Hazaar, where magic happens. I see this working as follows:

Check for new and removed tables as normal. This process is currently working and does not need to change.
Once this process is complete and all tables additions/removals have been detected, scan the create command list.
For each create command, scan the remove commands and look for tables that match. ie: same number of fields, all fields have the same name. This can be considered an exact match.
Alternatively, we could also try and detect similar tables where one or two fields have been removed, or renamed (I think data types should be pivot point here) and then maybe ask the question "Has table 'yaddayadda' been renamed to 'addayadday'?" to confirm the match in these cases.
Once we have a match, create a rename
If the table has differences, create update commands to bring the table up to date
Remove the create and remove commands that matches.

That should just about do it.

I need to have a think about how to handle tables that have been renamed. Currently, renaming a table is detected as a *remove* and a *create* action. This works for now and manages to get the schema updated and looking how it should. The problem is, this will cause all the data in the table to be lost, which may not be what we are after. I see two options here: 1. Let developers know that renaming a table is bad and will cause the data in the table to be lost (ie: the easy way out). 1. Try and figure out how to get the snapshot process to detect that a table is being renamed and instead of creating *remove* and *create* commands, create a *rename* command. I'm inclined to go with option two because hey, this is Hazaar, where magic happens. I see this working as follows: 1. Check for new and removed tables as normal. This process is currently working and does not need to change. 1. Once this process is complete and all tables additions/removals have been detected, scan the *create* command list. 1. For each *create* command, scan the *remove* commands and look for tables that match. ie: same number of fields, all fields have the same name. This can be considered an exact match. 1. Alternatively, we could also try and detect similar tables where one or two fields have been removed, or renamed (I think data types should be pivot point here) and then maybe ask the question "Has table 'yaddayadda' been renamed to 'addayadday'?" to confirm the match in these cases. 1. Once we have a match, create a *rename* 1. If the table has differences, create *update* commands to bring the table up to date 1. Remove the *create* and *remove* commands that matches. That should just about do it.

jamie commented

2014-03-06 01:35:40 +00:00

(Migrated from git.hazaar.io)

This has been added in 6ffed4010

This has been added in 6ffed4010

jamie commented

2014-03-06 01:40:02 +00:00

(Migrated from git.hazaar.io)

Reassigned to @jamie