Zardosht Kasheff <zardosht@gmail.com> writes:
I have spent some of my spare time looking into this. It turns out that MySQL Cluster already has this ability. They have the following handler functions listed below. I spent a weekend trying to port MySQL Cluster's alter table function (mysql_alter_table) over to 5.1.46.
- All storage engines use the new alter table, I want storage engines to opt in, to reduce the risk of bugs
Any thoughts?
Yes. I think you should use the new interface for everything. I remember when we did this work in cluster (I did the low-end table change part), and the alter table interface was designed as a general solution, not something to be used only for some special engines. I understand of course why you want to "reduce risk". This has been the approach taken with much community development in the last couple of years (Percona patches, Google patches, Facebook patches, etc): maintain isolated patches, trying to minimise the impact of each patch on the code base to keep things manageable as individual patches and reduce risk and effort needed. But recently I see so much community development happening that I believe it is necessary to move to the next phase. With your work, the Facebook group, my group at Monty Program, Perconas work, and other stuff, the development effort outside of MySQL@Oracle is on the same order of magnitude as that inside. Maintaining individual patches does not scale to that level of effort, in my opinion. Until MySQL@Oracle opens up their development to outside groups, we need another solution. I spend the first year on MariaDB just working to make everything we need available for full-scale development on the MySQL codebase for just this reason. But I recognise that there is still something missing for MariaDB to be useable for Facebook, Percona, you, etc. I think maybe it is the release model, if so we can fix it. Or use something else, it does not have to be MariaDB, but I strongly believe we need to coordinate our efforts. Within the next 6 months or so we have the merge with all of our still into MySQL 5.5 coming up, that will take considerable effort and is not something we should each repeat individually. So we need to find a model that works for all you people out in the trenches needing to put things in production use ASAP. But you guys also need at some point to start spending the extra effort to test, fix, and integrate new things properly, otherwise we end up with a huge spaghetti of patches that cannot be maintained. Just my thoughts, - Kristian.