Hi! >>>>> "Konstantin" == Konstantin Osipov <kos...@sun.com> writes:
Konstantin> * Michael Widenius <mo...@mysql.com> [09/01/30 14:53]: >> Its more important that we don't break things for current users than >> try to be concerned about possible wrong usage that no one seams to do >> or find important enough to complain about. Konstantin> Monty, I disagree with this statement. Our current users use the Konstantin> current versions of the server. It's a separate question of what Konstantin> support we're willing to give them and for how long. Konstantin> In the new versions we should hold high the expectations of new Konstantin> users, and they are about standard compliance, and also about ease Konstantin> of migration. Sorry, but the above is not true. We have asked user over and over again what they think about the standard and they have said it's not critical or even important to them.; What is important that we don't break their old applications! When going forward, we must prioritize old user to new ones! The old ones are our current or customers in the near future. If we make them unhappy we don't have a business anymore. The new users will mainly listen to old user if they should use MySQL or not. If we make the old ones angry, we don't get new users. Konstantin> sql_modes are not a solution since they make the server code a Konstantin> mess, and won't let us make everyone happy anyway. I disagree that it makes the code messy. The code depends on how you implement them. sql_modes are there to help people easier switch to a newer server and gives them time to upgrade their old applications over time. When you have an application with million of code, it will take time to find and fix all issues. Seeing able to resolve things when things are found to break by simply using a sql_mode may save the day for them. It's important that you see the usage of MySQL from theu user point of view; Saying that something is complex and we will not do it, will not satisfy a user that needs it. Konstantin> MySQL server needs a vision. Sticking to expectations of existing Konstantin> users is looking back into (not-so) glorious past. Our existing users is the second biggest user base for any database. We reached this level as MySQL has worked to their expectations. Trying to do things differently, like other companies have tried, will just lead to failures. Konstanting> Trying to make everybody happy is infeasible. Konstantin> Our only option is to move forward Konstantin> to meet expectations of our modern adopters, and they are largely Konstantin> more intelligent, with past database experience, so the standard Konstantin> compliance is high on their list. On what do you base your observation ? It's not what our users have been telling us on MySQL conferences. People are using MySQL because it's different and can satisfy their needs. Standards are useful, but not important for our current or future users. Getting the job done and not having downtime, even when upgrading, that is important! Konstantin> What's worse, is that while we're fighting internally when to make Konstantin> an incompatible change and when not, our change management process Konstantin> is a mess. That's another issue, but it's not any reason to abound features that some of our users may depend on. Konstantin> We introduce incompatible changes in every major release, so Konstantin> people are forced to migrate their applications manually again and Konstantin> again. And yet we can't plan our changes in a way that a bulk Konstantin> incompatible changes in a certain area are done at once, forcing Konstantin> people to look into the problem once only, rather than on every Konstantin> upgrade. That is a problem with our development processes, has nothing to do with sql modes. Konstantin> It's a pity we can't shift our focus and mental efforts from Konstantin> developing a shared understanding what incompatible changes are Konstantin> right and called for, to developing the best way of making Konstantin> changes. Just focusing on one area doesn't solve any problems. What is needed is to have a good understanding of all aspect of the problem. I agree that we need to change things. I disagree that doing incompatible changes without planning and carefull thinking about how this will affect our user base is the right way to go. Regards, Monty -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
