Webyog Forums > 5.1b4: Structure Sync Issues

Full Version: 5.1b4: Structure Sync Issues

Webyog Forums > SQLyog > SQLyog BETA Discussions

jrossiter

Mar 23 2006, 04:25 AM

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)

peterlaursen

Mar 23 2006, 07:04 AM

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.

peterlaursen

Mar 23 2006, 07:59 AM

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!

jrossiter

Mar 23 2006, 08:33 AM

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;

peterlaursen

Mar 23 2006, 08:38 AM

OK - thanks ...

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

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.