Skip to content
  • Jon Olav Hauglid's avatar
    54bfcfa9
    WL#6929: Move FOREIGN KEY constraints to the global data dictionary · 54bfcfa9
    Jon Olav Hauglid authored
    This worklog populates the new dictionary tables for foreign keys
    (mysql.foreign_keys and mysql.foreign_key_column_usage) whenever
    a foreign key is created or dropped. Note that foreign key information
    will not be stored for storage engines that do not support foreign
    keys (e.g. MyISAM) - however syntax checking will still be done.
    
    This worklog is limited in scope - the new dictionary tables
    for foreign keys are not used for I_S (see WL#6599) or by
    InnoDB (see WL#7595) yet. This worklog also does not implement
    metadata locking for foreign keys (see WL#6049).
    
    This worklog does introduce some user visible changes of behavior:
    - ER_FK_DUP_NAME is now reported more consistently in cases where
      duplicate foreign key names exist. Foreign key names have to be
      unique for a given schema.
    - Foreign key names are now limited to 64 characters similar to
      other identifiers.
    - If no foreign key name is given, a name is generated. For now
      we use the same name as generated by InnoDB. The format is
      (table_name)_ibfk_(counter).
    - More validity checking is done for foreign key definitions
      created for tables with storage engines that do not support
      foreign keys (even if the fks are not stored).
    
    Note that as metadata locking for foreign keys has not been
    implemented yet, any relevant changes to the parent table
    are not reflected in the foreign key definition. This will be
    fixed later after WL#6049 has been implemented.
    54bfcfa9
    WL#6929: Move FOREIGN KEY constraints to the global data dictionary
    Jon Olav Hauglid authored
    This worklog populates the new dictionary tables for foreign keys
    (mysql.foreign_keys and mysql.foreign_key_column_usage) whenever
    a foreign key is created or dropped. Note that foreign key information
    will not be stored for storage engines that do not support foreign
    keys (e.g. MyISAM) - however syntax checking will still be done.
    
    This worklog is limited in scope - the new dictionary tables
    for foreign keys are not used for I_S (see WL#6599) or by
    InnoDB (see WL#7595) yet. This worklog also does not implement
    metadata locking for foreign keys (see WL#6049).
    
    This worklog does introduce some user visible changes of behavior:
    - ER_FK_DUP_NAME is now reported more consistently in cases where
      duplicate foreign key names exist. Foreign key names have to be
      unique for a given schema.
    - Foreign key names are now limited to 64 characters similar to
      other identifiers.
    - If no foreign key name is given, a name is generated. For now
      we use the same name as generated by InnoDB. The format is
      (table_name)_ibfk_(counter).
    - More validity checking is done for foreign key definitions
      created for tables with storage engines that do not support
      foreign keys (even if the fks are not stored).
    
    Note that as metadata locking for foreign keys has not been
    implemented yet, any relevant changes to the parent table
    are not reflected in the foreign key definition. This will be
    fixed later after WL#6049 has been implemented.
Loading