Unsupported Screen Size: The viewport size is too small for the theme to render properly.

5.1b4: Structure Sync Issues

forums › forums › SQLyog › SQLyog BETA Discussions › 5.1b4: Structure Sync Issues

  • This topic is empty.
Viewing 4 reply threads
  • Author
    Posts
    • March 23, 2006 at 4:25 am #9556
      jrossiter
      Member

      UI:

      1. After comparison, the UI starts with the window scrolled all the way to the bottom

      2. Collapsing a folder sends the window scroll all the way to the bottom

      3. Foreign keys are corrupted on the target DB (ex: Source table contains 'Test_ibfk_1', target DB contains an entry for “<3-4 garbage chars>t_ibfk_1″.) It is always the first three bytes that are corrupted, however it appears that sometimes there is an extra garbage byte prepended. (Doesn't seem to effect the SQL output).

      4. If a single column/index/foreign key is modified in a table, every column/index/foreign key is selected unnecessarily. (I know this is a legacy issue, but what's the point of having checkboxes if you can't select one item out of many?)

      SQL:

      1. Multiple 'USE' commands are generated. Why not simply have a single USE at the top of the script?

      2. As noted in the Bugs forum for 5.0.2: Character set is not compared for existing tables, or copied for new tables. This is a serious issue because character set mismatches will prevent foreign keys from being created (much to my dismay and loss of 2 hours of yelling “Why in the hell won't you work?!”)

      3. When copying SQL for a table with a foreign key bad SQL is generated: (Note the alter with no changes, and no semi-colon)

      Code:
      /* Alter table in First database */
      alter table `testDB`.`testTable`

      /* Alter ForeignKey(s) in First database */
      USE `testDB`;

      ALTER TABLE testTable
      ADD CONSTRAINT `testTable_ibfk_1`
      FOREIGN KEY (`testColumn`) REFERENCES `testTable2` (`testColumn`);

      4. Foreign keys are created in separate alter blocks than the rest of the DB changes. (I can see this being intentional, but it's unnecessary as long as the SQL is sorted in a fashion to ensure that FKs are created after the colums and indexes exist)

    • March 23, 2006 at 7:04 am #20966
      peterlaursen
      Participant

      UI:

      1) No issue in my opinion.

      2) Agree that this should be fixed

      3) I don't understand! Where do you see that! I don't find anything garbled here! Could you provide two 'create statements' to reproduce this?

      4) Same as 3). It would be easier if you provided a reproducable example.

      SQL:

      1) No issue in my opinion. There are dozens of different ways.

      2) I answered this ..

      3) Same a s 2) above. Please provide a 'reproducable test case' in detail. I can't reproduce with my data.

      4) No issue in my opinion. There are dozens of different ways.

    • March 23, 2006 at 7:59 am #20967
      peterlaursen
      Participant

      Just let me add that as syncing of FK's is quite new with SQLyo 5.1 there could very well be some issues. Probably only a few people have tested this.

      So please detail your examples!

    • March 23, 2006 at 8:33 am #20968
      jrossiter
      Member

      UI:

      1. Small issue, but it is a usability and UI-standards issue. It makes it difficult to do a “top down” visual comparison, which is how every language that I know of reads. (RTL or LTR, it's always top to bottom)

      3. See below. The issue seems to only occur if the table structures are identical *except* for the FK definition. The FK entry for testDB2.testTable2 will be corrupted.

      4. Using the example below, in testDB2.testTable1 try and select *only* the extra column. It's not possible. You can select the entire table, or nothing. You can't just check one box. It's not a serious issue by any means, and the UI has “always” acted like this, but my question is simply “why bother going to the effort of having checkboxes for the sub-items if you can't select them”.

      SQL:

      1. It's not serious, but it's unnecessary duplication.

      2. I have a feeling this discussion could get long.

      3. The sample below demonstrates this as well. Again, the issue only occurs when there are no column changes necessary. It's building the alter command because of the FK, but because there are no column changes, it doesn't write any further data or end the statement with a ;.

      Code:
      CREATE DATABASE testDB1;
      USE testDB1;
      CREATE TABLE testTable1 (
      `primaryColumn` CHAR(32) NOT NULL,
      PRIMARY KEY (`primaryColumn`)
      ) ENGINE=InnoDB;
      CREATE TABLE testTable2 (
      `fkColumn` CHAR(32) NOT NULL,
      PRIMARY KEY (`fkColumn`),
      FOREIGN KEY `fk_test` (`fkColumn`)
      REFERENCES `testTable1` (`primaryColumn`)
      ON DELETE CASCADE
      ON UPDATE CASCADE
      ) TYPE=InnoDB;
      CREATE DATABASE testDB2;
      USE testDB2;
      CREATE TABLE testTable1 (
      `primaryColumn` CHAR(32) NOT NULL,
      `secondColumn` CHAR(32) NOT NULL,
      PRIMARY KEY (`primaryColumn`)
      ) ENGINE=InnoDB;
      CREATE TABLE testTable2 (
      `fkColumn` CHAR(32) NOT NULL,
      PRIMARY KEY (`fkColumn`)
      ) TYPE=InnoDB;
    • March 23, 2006 at 8:38 am #20969
      peterlaursen
      Participant

      OK – thanks …

      I understand now!

      It is an issue with the newly introduced FK-sync, I believe.

  • Author
    Posts
Viewing 4 reply threads
  • You must be logged in to reply to this topic.