1. 07 Jul, 2002 1 commit
  2. 17 Apr, 2002 1 commit
  3. 04 Mar, 2002 1 commit
  4. 01 Mar, 2002 1 commit
  5. 01 Feb, 2002 3 commits
    • Robert Ricci's avatar
      Added some checks for key types, etc. that are currently not used in · 6d6d755b
      Robert Ricci authored
      the testbed database anywhere. Otherwise, they could accidentally be
      mistaken for columns.
      
      Now, all table options (the 'create_definition' rule in the MySQL
      documentation for 'CREATE TABLE') are recognized.
      6d6d755b
    • Robert Ricci's avatar
    • Robert Ricci's avatar
      New script: schemadiff - a script to sync up the schemas of two · 83341399
      Robert Ricci authored
      databases. This script is not quite ready for usage - I've done some
      testing, but more testing shuld be done before it's widely used.
      
      From the usage message:
      Prints on stdout a set of SQL commands to change the database
      from file1 so that it has the same schema as the database from
      file2 (same argument order as diff)
      
      The files given are the output of mysqldump for the two databases -
      the dump ouput can contain oly column definitions, or it can contain
      row information (which is ignored.)
      
      This script can find and fix: created/dropped tables, created/dropped
      columns, columns that have had type chages, renamed columns, changes
      in primary and other (non-primary) keys. It keeps columns in order
      when creating new tables and adding columns.
      
      There a few things that I still want to do with this script:
      
      Make a framework for populating columns. For example, if column 'foo'
      is added, it would look in some location for a script that would
      populate this column.
      
      Create a wrapper that connects to the database to be updated, backs it
      up, locks all tables, applies the changes, and can recover if
      something goes wrong.
      
      Add a 'safe mode' (which would be the default), which won't remove
      columns or tables.
      
      There are a few caveats:
      
      Columns that have been _both_ renamed and had their type changed will
      be dropped and re-created, since it's impossible to detect this case.
      
      There may be some ordering issues. For example, the primary key for a
      table may need to be dropped before you can allow a column that used
      to be in the primary key in the primary key to contain NULLs.
      
      Will only work in one direction - a master-slave type relationship. If
      used between databases that have _both_ been changed, changes in the
      database being updated first will be lost.
      83341399