mysqldump feature request
It would be nice to have an option for mysqldump to put the building of indexes after the insert statements to speed up loading. - 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
MySQL 4.0.1 released
The Windows download is still 4.0.0a . for mail filter: database,sql,query,table - 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: 4.0.1?
That would be nice. I have been hoping for it since Nov 23 when there was a post saying that it would be out in the next week. http://lists.mysql.com/cgi-ez/ezmlm-cgi?2:mss:118:200111:nmfbdddincnalmjpnhng Fournier Jocelyn [Presence-PC] wrote: Hi, It should be really soon, Monty wrote me today he was building a distribution with the current 4.0.1 code... Best Regards, Jocelyn Fournier Presence-PC - Original Message - From: Franklin Schmidt [EMAIL PROTECTED] Does anyone know when 4.0.1 will be released? dear mail filter, use SQL to QUERY DATABASE TABLEs - 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
4.0.1?
Does anyone know when 4.0.1 will be released? dear mail filter, use SQL to QUERY DATABASE TABLEs - 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
descending keys
Why doesn't MySQL support descending keys in indexes? - 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: Default forced on MySQL
I tried compiling with the DONT_USE_DEFAULT_FIELDS flag. Now no defaults are used, even the ones I ask for. So MySQL gives me a choice of getting defaults I don't ask for (with the regular version) or not getting defaults I do ask for (with the DONT_USE_DEFAULT_FIELDS). How about giving me what I ask for and not giving me what I don't ask for? Is that too much to ask? - 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: Default forced on MySQL
DownloadFAST.com wrote: But hey apparently I did finally get a solution from a helpful chap on this list What is it? I would like to know. My email is [EMAIL PROTECTED] P.S. for spam filter - database,sql,query,table - 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: Default forced on MySQL
Sinisa Milivojevic wrote: As your entire discussion centers on the non-existence of NO DEFAULT, I will briefly comment only on that. I would like to add my support for NO DEFAULT. The lack of this feature is by far the worst thing about MySQL. Forcing default on all columns is a design decision which had to be forced for many reasons. Most important reason of all is that MyISAM tables are designed for utter speed. Therefore, they are not transactional tables nor do they have any form of pre-imaging. As on the other hand, MySQL supports multi-row inserts (and soon even multi-table updates), having defaults was a necessity as rolling back upon hitting the error in user's data in N'th row is simply impossible. I don't get this argument. What happens when a unique index is violated? Isn't this the same problem? - 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: Default forced on MySQL
I just found the following at http://www.mysql.com/doc/B/u/Bugs.html -- Because MySQL allows you to work with table types that don't support transactions, and thus can't rollback data, some things behave a little differently in MySQL than in other SQL servers. This is just to ensure that MySQL never need to do a rollback for a SQL command. This may be a little awkward at times as column values must be checked in the application, but this will actually give you a nice speed increase as it allows MySQL to do some optimisations that otherwise would be very hard to do. If you set a column to an incorrect value, MySQL will, instead of doing a rollback, store the best possible value in the column: If you try to store a value outside the range in a numerical column, MySQL will instead store the smallest or biggest possible value in the column. If you try to store a string that doesn't start with a number into a numerical column, MySQL will store 0 into it. If you try to store NULL into a column that doesn't take NULL values, MySQL will store 0 or '' (empty string) in it instead. (This behavior can, however, be changed with the -DDONT_USE_DEFAULT_FIELDS compile option). MySQL allows you to store some wrong date values into DATE and DATETIME columns. (Like 2000-02-31 or 2000-02-00). If the date is totally wrong, MySQL will store the special -00-00 date value in the column. If you set an ENUM column to an unsupported value, it will be set to the error value 'empty string', with numeric value 0. If you set an SET column to an unsupported value, the value will be ignored. -- This is very appropriately in the page for Known Errors and Design Deficiencies in MySQL. I think all of the above are design deficiencies. The right behavior for all these cases is to generate an error, even at some cost to performance. - 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: Default forced on MySQL
Kodrik wrote: Understand also that the check for a uniq index has to be made by a call to the DB so it makes sense the DB does it, but a check on the content of a variable can be made by one line of code without any call to the db. Anything that the database does, one can also do in code. I could make sure a column is unique by checking it in code before inserting or updating values, but I prefer that it is done in the database with a unique index because this centralizes it. For the same reason, I prefer having NO DEFAULT in the database, because this centralizes the check and avoids errors. The worst thing any development tool can do is silent unwanted favors. Java and C don't do unwanted favors which is why they are great. Javascript and most Microsoft tools do lots of unwanted favors which is why I hate them. This is a personal preference but I suspect most programmers with experience in large projects share this preference. MySQL does many unwanted favors to avoid rollback. This was a bad design decision because update speed usually doesn't matter much. What matters is the speed of reading and reliability of the data. My point about unique indexes is that I assume that this forces MySQL to deal with the rollback problem anyway. If you have a multi-row insert and one of these rows violates a unique index, what does MySQL do? You either do a rollback or lose atomicity. This looks like exactly the same problem that you would have implementing NO DEFAULT or any other column value sanity check in the database. - 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
