forums › forums › SQLyog › SQLyog BETA Discussions › 5.1b4: Structure Sync Issues
- This topic is empty.
-
AuthorPosts
-
-
March 23, 2006 at 7:04 am #20966
peterlaursen
ParticipantUI:
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
ParticipantJust 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
MemberUI:
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
ParticipantOK – thanks …
I understand now!
It is an issue with the newly introduced FK-sync, I believe.
-
-
AuthorPosts
- You must be logged in to reply to this topic.