RENAME DATABASE was originally introduced to support the new
object-name-to-file-name encoding, as added by WL#1324.

It does not maintain proper object locking and has other issues.
This is reflected in the following bug reports:
BUG#28360
BUG#17565
BUG#30099
BUG#21741

Also RENAME DATABASE currently has the following problems, not reported
as bugs:

 * leads to deadlocks
 * leaves inconsistent data in case of a failure
 * doesn't update triggers that happen to say 'create trigger
   after insert on dbname.tablename', not just
   'create trigger after insert on tablename',
   Rename fails with an error if there is such a trigger.
 * doesn't work if there is at least one view in the database,
   fails with ER_CHANGING_SCHEMA_IS_NOT_ALLOWED.
 * doesn't update fully qualified object references in bodies of functions,
   procedures, events
 * doesn't move temporary tables
 * doesn't invalidate caches of prepared
   statements, stored procedures, functions
 * ignores GLOBAL READ LOCK.

Complete support for RENAME DATABASE was not planned in version 5.1.
Since 5.1 is approaching its GA status, we can not implement this feature fully
or fix the reported bugs. It will also require significant changes in data
dictionary
implementation and meta-data locking, if to be done properly.

Therefore, as is suggested in this worklog, the problematic syntax is phased out
and replaced with syntax that still supports the needs of WL#1324 and mysqlcheck
client program, but does not allow for usage that leads to bugs.

We're removing an incomplete feature from the server.

The scenario in which RENAME DATABASE is employed by mysqlcheck is the 
following:
- if there is a database name that contains special characters, such as, e.g., 
'-'
  - this database name is converted to the new format, in which these characters
are replaced with encoded sequence in ASCII, as per WL#1324

In order to support this task, a new syntax is introduced:

ALTER DATABASE <name> UPGRADE DATA DIRECTORY NAME

The semantics of this statement is:
- if the <name> is not in the encoding of WL#1324, it is converted to the
encoding of WL#1324

The current implementation of RENAME DATABASE (See WL#757) will be used.

1)



The statement:

  RENAME DATABASE <old> TO <new>

is *removed* from 5.1, instead of being deprecated.



Rationale:

- The very existence of this statement is the root cause of the issue,

keeping it won't solve the concerns about it's implementation

- This statement is used internally only, by the upgrade process

- This statement was introduced in 5.1 only, there is no need to support it

for backward compatibility.



2)



A new statement is implemented:

  ALTER DATABASE <old_50_name> UPGRADE DATA DIRECTORY NAME



Rationale:

- The ALTER DATABASE syntax is semantically closer to the operation

  performed

- only 1 name is needed. Providing 2 names (old and new) caused the issues

reported, since with 2 names the implementation can be leveraged to not only

change the database name encoding, but also the database logical name, which

is not fully supported.

- UPGRADE DATA DIRECTORY NAME has been chosen since it only uses already

  existing keywords, while describing the operation performed.

Simple syntax change in the parser,

reusing the existing implementation for the runtime part.



No detail design needed.

You must be logged in to tag this worklog

No Comments yet