MySQL Community Server 5.1.43 has been released
Dear MySQL users, MySQL Community Server 5.1.43, a new version of the popular Open Source Database Management System, has been released. MySQL 5.1.43 is recommended for use on production systems. For an overview of what's new in MySQL 5.1, please see http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html For information on installing MySQL 5.1.43 on new servers or upgrading to MySQL 5.1.43 from previous MySQL releases, please see http://dev.mysql.com/doc/refman/5.1/en/installing.html MySQL Server is available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/ Not all mirror sites may be up to date at this point in time, so if you can't find this version on some mirror, please try again later or choose another download site. We welcome and appreciate your feedback, bug reports, bug fixes, patches, etc.: http://forge.mysql.com/wiki/Contributing For information on open issues in MySQL 5.1, please see the errata list at http://dev.mysql.com/doc/refman/5.1/en/open-bugs.html The following section lists the changes in the MySQL source code since the previous released version of MySQL 5.1. It may also be viewed online at http://dev.mysql.com/doc/refman/5.1/en/news-5-1-43.html Enjoy! === C.1.2. Changes in MySQL 5.1.43 InnoDB Plugin Notes: * This release includes InnoDB Plugin 1.0.6. This version is considered of Release Candidate (RC) quality. Functionality added or changed: * Partitioning: The UNIX_TIMESTAMP() function is now supported in partitioning expressions using TIMESTAMP columns. For example, it now possible to create a partitioned table such as this one: CREATE TABLE t (c TIMESTAMP) PARTITION BY RANGE ( UNIX_TIMESTAMP(c) ) ( PARTITION p0 VALUES LESS THAN (631148400), PARTITION p1 VALUES LESS THAN (946681200), PARTITION p2 VALUES LESS THAN (MAXVALUE) ); All other expressions involving TIMESTAMP values are now rejected with an error when attempting to create a new partitioned table or to alter an existing partitioned table. When accessing an existing partitioned table having a timezone-dependent partitioning function (where the table was using a previous version of MySQL), a warning rather than an error is issued. In such cases, you should fix the table. One way of doing this is to alter the table's partitioning expression so that it uses UNIX_TIMESTAMP(). (Bug#42849: http://bugs.mysql.com/bug.php?id=42849) Bugs fixed: * Security Fix: For servers built with yaSSL, a preauthorization buffer overflow could cause memory corruption or a server crash. We thank Evgeny Legerov from Intevydis for providing us with a proof-of-concept script that allowed us to reproduce this bug. (Bug#50227: http://bugs.mysql.com/bug.php?id=50227, CVE-2009-4484 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4484)) * Important Change: Replication: The RAND() function is now marked as unsafe for statement-based replication. Using this function now generates a warning when binlog_format=STATEMENT and causes the the format to switch to row-based logging when binlog_format=MIXED. This change is being introduced because, when RAND() was logged in statement mode, the seed was also written to the binary log, so the replication slave generated the same sequence of random numbers as was generated on the master. While this could make replication work in some cases, the order of affected rows was still not guaranteed when this function was used in statements that could update multiple rows, such as UPDATE or INSERT ... SELECT; if the master and the slave retrieved rows in different order, they began to diverge. (Bug#49222: http://bugs.mysql.com/bug.php?id=49222) * Partitioning: When used on partitioned tables, the records_in_range handler call checked all partitions, rather than the unpruned partitions only. (Bug#48846: http://bugs.mysql.com/bug.php?id=48846) See also Bug#37252: http://bugs.mysql.com/bug.php?id=37252, Bug#47261: http://bugs.mysql.com/bug.php?id=47261. * Partitioning: A query that searched on a ucs2 column failed if the table was partitioned. (Bug#48737: http://bugs.mysql.com/bug.php?id=48737) * Replication: A LOAD DATA INFILE statement that loaded data into a table having a column name that must be escaped (such as `key` INT), caused replication to fail when logging in mixed or statement mode. In such cases, the master wrote the LOAD DATA event to the binary log without escaping the field names. (Bug#49473: http://bugs.mysql.com/bug.php?id=49473) See also Bug#47927: http://bugs.mysql.com/bug.php?id=47927. * Replication: Spatial data
Re: 50 things to know before migrating from Oracle to MySQL
On 01/29/2010 07:24 PM, Shawn Green wrote: Rudy Lippan wrote: On 01/29/2010 02:57 PM, Chris W wrote: Hardcore stupid if you ask me. I suppose it is possible to have a valid reason (can't imagine what it might be) for using more than 61 How about complex data requirements? Depending on the resolution of your data set, I could see a simple person-type object that contained name, address, SSN, mother, and birth_info starting to approach the limit. In a simplified Object-to-Database map, most object types (classes) equate to a single table. Each table will contain several columns. Each column will represent one particular property of the object. For objects that contains lists of sub-values or sub-objects, you use another table (usually called a child) related to the first (often called a parent). You are speaking to a simplified mapping; whereas, I was suggesting one valid reason for needing many tables in a join, viz., you have a requirement for *high resolution* data set. Maybe think of a genealogy-type database where someone might have a good reason inquire whether 2 people lived within 5 miles of each other between July 23, 1843 and September 18, 1858. Simple right? One little query. But now, let us add that the city was renamed 4 times, lost in a war to another country, recaptured, annexed by another city which was eventually dissolved for lack of tax revenue. Or to get a few more tables in the mix: Could those people have lived on the same street, same block, within 15 houses? And let us not forget that the street has been renamed many times, renumbered a few (using different numbering schemes), some properties were subdivided, and two adjoining properties were held, at one point, in single and separate ownership but ended up being purchased by the same person during a time when the zoning laws forced a merger. Sure it is overkill for your shopping cart, but not for my database of all worldly knowledge :) It is just a matter of how you look it. BTA, if you were writing your shopping cart for a genealogy website that had the above database, you might just create a view, city(city_id, current_name), and use that id when storing user/credit card info. OK, after this last statement I will cut you some serious slack. However, and I hope you agree, unless someone is using some rather obscene normalization, most queries should not require joins of more than 10 or 12 tables to resolve. Or using multiple imported data sets that are each normalized, or using a code generator, or, or ,or. In general, I agree, but only in general. My personal thumbrule is that if I have more than about 7-9 tables in a single query, I should probably attack the problem in stages. I do this because the physical act of logically (internally) representing all of those columns across all of those row permutations in memory can become a burden to process. Here you are talking about working around limitations: Either yours or the database's. -r -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: 50 things to know before migrating from Oracle to MySQL
On 1/29/10 5:03 PM, mos mo...@fastmail.fm wrote: I noticed the article didn't say how much money you'll save by not paying through the nose for Oracle per server licensing, the cost of upgrading your hardware to get some speed out of Oracle, or the cost of having to hire one or more Oracle administrators to manage and tweak the database. how much does an oracle programmer who can maintain your queries with more than 61 joins cost, in, say, usd/hr? -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: 50 things to know before migrating from Oracle to MySQL
I once was selling a system to an organization. I recommended an IBM AIX box for about $30,000. A competitor was charging $30,000 for the software and said it had to run on an AS/400 that would cost in excess of $200,000. I lost the sale because the IBM salesman said, quite candidly, 'I make more commission on the AS/400 so that's the one I am selling.' Oracle is very similar. They are managed to make money. I suspect we will see licensing fees and required support contracts because they can now charge them. And, an Oracle consultant to write a join with 100-200 joins? Oracle will sell it if they can convince the customer. Just some thoughts. - Original Message - From: Tom Worster f...@thefsb.org To: mos mo...@fastmail.fm; mysql@lists.mysql.com Sent: Sunday, January 31, 2010 7:39 PM Subject: Re: 50 things to know before migrating from Oracle to MySQL On 1/29/10 5:03 PM, mos mo...@fastmail.fm wrote: I noticed the article didn't say how much money you'll save by not paying through the nose for Oracle per server licensing, the cost of upgrading your hardware to get some speed out of Oracle, or the cost of having to hire one or more Oracle administrators to manage and tweak the database. how much does an oracle programmer who can maintain your queries with more than 61 joins cost, in, say, usd/hr? -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=c...@etrak-plus.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
