Dumping binary data
If a table has a blob type containing binary data, like jpeg images or PDF files for example, can mysqldump be told to encode the data so it is ASCII compatible? (using uuencode or something like that..) I am not sure of the 'right' way to do this, but some informal tests where I dump and reload a table seems to corrupt the binary data. Thanks, -Bob - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
RE: Foreign keys in mysqldump?
Heikki, You are the man! I am glad you are addressing these issues in 3.23.50. They will make foreign key support in MySQL much more robust (in my opinion, anyway..) Is the .50 release available yet? If not, do you have a timeline for when it will be, and when it would be recommended to use in production work? Thanks much, -Bob -Original Message- From: Heikki Tuuri [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 4:50 AM To: Bob McLaughlin; MySQL Mailing List Subject: Re: Foreign keys in mysqldump? Bob, I have now improved foreign key support so that version 3.23.50 does 1. show the FOREIGN KEY definitions when you call SHOW CREATE TABLE; this should also show them in mysqldumps; 2. preserve FOREIGN KEY definitions in ALTER TABLE and CREATE INDEX; 3. allow backquotes around column and table names in foreign key definitions: backquotes are produced by SHOW CREATE TABLE; 4. allow adding a new foreign key constraint ot a table through ALTER TABLE ... ADD CONSTRAINT FOREIGN KEY (...) REFERENCES ... (...); remember though that you first have to create the appropriate indexes on the parent and child table so that InnoDB approves the constraint. I try to get also in .50 a command SET FOREIGN KEY CONSTRAINT CHECKS=0 which allows you to disable them when you import dumped tables in a wrong order regarding to the foreign key definitions. In versions 3.23.50 the only way to 'dump' foreign key definitions is to call SHOW TABLE STATUS FROM ... which prints them in the table comments. Best regards, Heikki Tuuri Innobase Oy --- Order technical MySQL/InnoDB support at https://order.mysql.com/ Speed up adding of features to MySQL/InnoDB through support contracts See http://www.innodb.com for the online manual and latest news on InnoDB -Original Message- From: Bob McLaughlin [EMAIL PROTECTED] To: MySQL Mailing List [EMAIL PROTECTED] Cc: Heikki Tuuri [EMAIL PROTECTED] Date: Monday, March 11, 2002 8:11 PM Subject: Foreign keys in mysqldump? When I do a mysqldump and include table creation, it does not seem to include the foreign key constraints in the create table statements of the InnoDB tables. Is there a command line switch or other way to make this happen? Thanks, -Bob - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Foreign keys in mysqldump?
When I do a mysqldump and include table creation, it does not seem to include the foreign key constraints in the create table statements of the InnoDB tables. Is there a command line switch or other way to make this happen? Thanks, -Bob - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Alter Table with InnoDB table type having foreign keys
A humble suggestion for the development team I went through and looked at some of the postings regarding using ALTER TABLE with InnoDB tables and the resulting loss of foreign key constrains. I was disappointed to learn about the need to use the create/drop workaround. The main reason I considered using InnoDB tables was to have a MySQL database that could ensure referential integrity. The thought that a command (ALTER TABLE) would silently break RI makes me very uneasy, and lessens the value I see in using MySQL. (OK, MySQL-Max) I understand that in MySQL the alter table command may in fact transparently do a create, drop and/or rename of tables, regardless of table type. But it still makes no sense to me that the ALTER TABLE command does not maintain foreign key constraints for the InnoDB table type. If MySQL does an internal create and drop to execute an alter table statement, and the table in question has a primary key, isn't the primary key transparently recreated? Isn't the same true for all other constraints?? (If not, please let me know!!) Why then shouldn't MySQL recreate the foreign key constraints too? If the reason is because the file is temporarily copied to a non InnoDB table type, couldn't the foreign key information be held temporarily in another object of some sort and applied after conversion back to InnoDB? Of course, I understand that there are priorities in development, and one should not expect to have all the bells an whistles the right away. That said, I shudder every time I open myPHPAdmin and see how easy it would be for any developer or administrator to break foreign key constraints. Therefore, I was hoping that you could consider adding foreign key support to the ALTER TABLE command, or at least consider adding an option such as innodb_fail_alter_table_with_fk that would warn or fail the alter table statement if the table type was InnoDB and foreign keys were going to be dropped. If this latter option was implemented, it would prevent RI from being quietly lost. Thanks much, -Bob - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
