alter() prompts user when table definition has not changed

[rly]

Bug Report

Description

When the table definition is written in a particular way, MyTable.alter() asks the user whether to alter the table, regardless of whether the table definition has changed. Specifically, this occurs (at least) when:

• the data type "blob" is written as "BLOB"
• the default string uses single quotes
• enum type has spaces separating options
• enum type uses double quotes or non-escaped single quotes

Reproducibility

Include:

• Windows
• Python 3.8.10
• datajoint/mysql docker
• both 0.13.2 and master branch
• Minimum number of steps to reliably reproduce the issue

import datajoint as dj
schema = dj.schema('test')
@schema
class Device(dj.Manual):
    definition = """
    device_name: varchar(200)
    ---
    system = "Other": enum("SpikeGadgets", "Other")
    description='': varchar(1000)
    parameters: BLOB
    """
    pass
Device.alter()
Device.alter()

Output:

ALTER TABLE `test`.`device`
	MODIFY `system` enum("SpikeGadgets", "Other") NOT NULL DEFAULT "Other" ,
	MODIFY `description` varchar(1000) NOT NULL DEFAULT '' ,
	MODIFY `parameters` BLOB NOT NULL 

Execute? [yes, no]:  yes
Table altered
ALTER TABLE `test`.`device`
	MODIFY `system` enum("SpikeGadgets", "Other") NOT NULL DEFAULT "Other" ,
	MODIFY `description` varchar(1000) NOT NULL DEFAULT '' ,
	MODIFY `parameters` BLOB NOT NULL 

Execute? [yes, no]:  yes
Table altered

This can be worked around by avoiding those four conditions:

@schema
class Device2(dj.Manual):
    definition = """
    device_name: varchar(200)
    ---
    system = "Other": enum(\'SpikeGadgets\',\'Other\')
    description = "": varchar(1000)
    parameters: blob
    """
    pass

This is confusing to users (I didn't change the table! Did the alter command work?).

• Complete error stack as a result of evaluating the above steps n/a

Expected Behavior

alter() should not prompt user when table definition has not changed.

Screenshots

Additional Research and Context

[CBroz1]

Also worth noting: unlike drop, alter fails silently when user has insufficient privileges. This might would be worth adding to a check that fixed the above