An open MySQL bug receives a real Birthday cake
bugs.mysql.com
bugs.mysql.com
I mentioned some Django bugs that are huge for us that were finally fixed in 1.6 in another thread [1]. I'd have personally pledged a couple hundred dollars to have them fixed, and probably could have gotten considerably more pledged from my company. Does this tool/platform exist and I just don't know about it?
[1] https://news.ycombinator.com/item?id=5958281
[Edit]
Thanks for the replies. Pledgie and bountysource look interesting and I suppose really close to what I was imagining, in spirit. Fundamentally, I'd like to see something well-executed help formalize the process behind what motivated Andrew's awesome Django migrations kickstarter [2]. I really like the way that came together because it had the buy-in of the team, and there-by inspired confidence in potential backers.
[2] http://www.kickstarter.com/projects/andrewgodwin/schema-migr...
Open source developers don't bite, and they never say no to a bit of extra cash :)
Thing is I likely would have done the work anyway. Bugs are community issues that effect everyone and contributing fixes for them keeps an open source project vibrant and active. But instead of feeling good about fixing some obscure bug I felt like I'd been used by someone who didn't want to pay for a developer.
The motivational approach I took was slightly different than crowdfunding. Instead of directly funding the tasks you want to see completed, the bounties are donations to charity made on behalf of the tasks. They can be either made immediately to establish your level of seriousness or made when the task completes, to provide ongoing motivation.
Since I am focused primarily on motivating city governments and businesses, I felt the same way as you: direct funding is not the right thing to do. These governments and businesses already have funds. If I want to sway their decision-making processes in some unusual way, my experiment is using public charitable donations.
Just as a demonstration, I just created a task for this (admittedly, not really what I have in mind for my site, but I'll take whatever eyeballs I can get) [2].
[1] https://www.brianstaskforce.com/
[2] https://business.brianstaskforce.com/task/385/oracle-address...
Still, I like your project quite a bit. Looks very nicely executed.
http://funding.openinitiative.com/
In development: https://snowdrift.coop/
To anyone not yet familiar, Maria is a really exciting fork of MySQL - https://mariadb.org/
> It's recently replaced mysql in redhat builds, so it's definitely on the up.
-- "Red Hat Says No MariaDB/MySQL Decision Made." The H Online, 18 June 2013 (http://www.h-online.com/open/news/item/Red-Hat-says-no-Maria...)
Does it really? I mean, sure, they are both RDBMS's, but that's a pretty broad market. Are there really that many use cases where, with the current market, people who are using MySQL would have Oracle as their next choice or vice versa?
I can see an argument that MySQL competes with some of the same products that Oracle DB competes with (but in different market segments than where Oracle DB does), but I don't see them as directly competitive in any significant sense.
I'm not a certified DBA so take this with a grain of salt, but it seems that any non-trivial use of Oracle systems ramp up in cost very quickly. Both in terms of hard cash and time in education/training.
Good point; I was considering mostly the situation where there isn't something already on hand, but it makes sense that there would be quite a lot of times where MySQL and Oracle DB are considered alternatives for a new project/application by shops who already have an existing installation of one or the other.
These days, that line may be blurred a little bit, and you can see how both paradigms (and more!) can be combined into a single product with PostgreSQL, but I feel like the MacBook analogy really sums up the way I feel about these two systems.
I don't think the MBPro/MBAir comparison is quite right. I think it's more like MBAir versus Mac Pro: it is very easy to see a single person having both of them and utilizing both of them extensively.
RDS users?
That's where a service like http://freedomsponsors.org comes in handy ;-)
This is how it works:
1) Someone places a bounty for a problem (tipically an issue registered on an issue tracker)
2) More people might want to sponsor the same issue
3) A developer solves the issue
4) The sponsors verify the solution and pay the developer
The FreedomSponsors website itself is an open source web application, written in Django. Funny fact - some of its own issues have been sponsored in the website.
The source code - along with instructions on how to run it - can be found on Github. https://github.com/freedomsponsors/www.freedomsponsors.org
[Totally unsolicited... I'd vote to change it's name. I know it seems silly/shallow but I thought of a million and a half things that it might be before I clicked he link, and none of them were even close to what it is. (Mostly I would have assumed it to be a Koch Brothers fundraising organization)]
http://www.youtube.com/watch?v=oAiVsbXVP6k
It's got a real Joker laugh going on toward the end.
Also, I wonder why he chose to record it in his bathroom. Those are definitely shower curtains and the echo is definitely bathroom-esque. Maybe for acoustics.
$ mysqldump -d my_database | sed 's/ AUTO_INCREMENT=[0-9]*\b//' > dump.sqlOnly posting this because I've done that before :)
According to Wikipedia: "Hydrogen fluoride is a highly dangerous gas, forming corrosive and penetrating hydrofluoric acid upon contact with tissue. The gas can also cause blindness by rapid destruction of the corneas."
They want to implement this feature server side, which means that they either have to add: (1) A new server setting (SET SHOW_CREATE_TABLE_FORMAT = Blah) -or- (2) New syntax (SHOW CREATE TABLE NOAUTOINC mytable).
Adding new settings is always evil, and adds to product confusion/complexity.
Adding new syntax is a bit evil in MySQL's case since they use a generic yacc parser, and might have to add a new reserved word (truthfully, I'm not 100% sure on that one). There is also a preference to only add reserved words to major new versions.
What does this bug cause?
The bug requests that the table definition written to the dump file by this utility not contain the current value of the AUTO_INCREMENT sequence when the option to dump only definitions, not data, is used.
Nonetheless, it's a lot more complicated than it would seem to "just reclaim the space".
In our use case we're making very heavy usage of table partitioning (over 500 partitions for some of our very large tables). Because each partition is effectively another table under the covers, if we were to use innodb_file_per_table then we'd have tens of thousands of files. This means a lot more file handles being opened/closed (as well as the obvious ulimit gotchas for the uninitiated). This noticeably hampered query performance when seeking data from random partitions.
Current shop is not running file_per_table, and has little reason to do so at ~30GB database file size. Still, dropping the table and not reclaiming any space was a rude awakening. Combine that the fact that storage was an AWS EBS sized pretty close to its limit (50GB). I could not perform two iterations of a test import without first rm'img the file. Lame.
Switched to postgresql now - just works!
Also, the SQL syntax is usually a pain to get it first (MySQL is much more tolerant for a newcomer)
And yes, PSQL commands usually work in MySQL (except for the specific stuff, like \dt but that's not even SQL so...)
I find it much easier from an admin and dev perspective. It is less forgiving, that is correct, but that's a good thing. Oh and the documentation is wonderful compared to MySQL.
Plus it works properly.
He also is hating on PHP in that article, which seems like prime HN bait, because as it does every time there is a PHP hate article on here, everyone actually doing real work comes and and says 'Okay, have fun with your rubies and nodes'.
With all that said, recently a lot of our data has started to be organized outside of MySQL (a lot more Couchbase and Solr usage), but MySQL is still there driving the core data. I'd say it all boils down to right tool for the job.
Please feel free to use as-is and integrate it into mysqldump. I can't be bothered to create an account on bugs.mysql.com.
--
[1] http://pastie.org/8092330 (EDIT: The parser wasn't fully correct, use [2])
for tbl in $(mysql -BNe "SELECT DISTINCT TABLE_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE EXTRA = 'auto_increment' AND TABLE_SCHEMA = 'mydb'"); do
mysql -e "ALTER TABLE ${tbl} AUTO_INCREMENT=1" mydb
done
Note: That code will require a bit of modification if you make the mistake of having spaces in your table name.
#!/bin/sh
mysqldump --no-data $* | sed 's/ AUTO_INCREMENT=[0-9]*//' | egrep -v '^-- (MySQL dump|Server version|Dump completed on)'
The existing behavior makes more sense anyway, as it preserves 'truncate table' <=> 'restore nodata dump' equivalence better.