List:General Discussion« Previous MessageNext Message »
From:Michael Widenius Date:February 3 2009 4:05pm
Subject:Re: WL#946 and Changing time literal format
View as plain text  
Hi!

>>>>> "Konstantin" == Konstantin Osipov <kostja@stripped> writes:

Konstantin> * Michael Widenius <monty@stripped> [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
Thread
Re: WL#946 and Changing time literal formatRoy Lyseng25 Jan
  • Re: WL#946 and Changing time literal formatMichael Widenius30 Jan
Re: WL#946 and Changing time literal formatPeter Gulutzan25 Jan
Re: WL#946 and Changing time literal formatMichael Widenius30 Jan
  • Re: WL#946 and Changing time literal formatKonstantin Osipov30 Jan
    • Re: WL#946 and Changing time literal formatJoerg Bruehe30 Jan
      • RE: WL#946 and Changing time literal formatJerry Schwartz30 Jan
    • Re: WL#946 and Changing time literal formatMichael Widenius3 Feb
      • Re: WL#946 and Changing time literal formatKonstantin Osipov5 Feb
        • Re: WL#946 and Changing time literal formatKonstantin Osipov5 Feb