Rant from Slashdot Article, Constraint on Types
« previous entry | next entry »
Mar. 31st, 2009 | 07:57 am
I've been reading through the comments on the Slashdot article from yesterday and I found this gem:
I have always agreed with the above. When we set out to create the "strict" mode within MySQL we could never get agreement on the above sort of problems. Personally I have despised this stuff for over a decade. I know where they come from, aka the limitations of Unireg (the original code), but I have always thought that we should fix this sort of thing (the first time I met Ann Harrison we were both in a room in Germany ranting about how bad this stuff is).
Guess what we did in Drizzle?
We have fixed all of these issues. I go through the manual from time to time to make sure we haven't left any of this stuff in. If we find ones we missed, we fix them.
There was a lot of these sorts of design decisions. The internal conversion system was never really designed around the concept that "some conversions should not happen."
The rule is simple, if the data doesn't fit within the constraint of the type, we need to toss an error, not just "warn" the user.
No "automagic" sorts of conversions.
Always do what the user expects.
No Magic.
No Gotchas.
When people ask me about the differences between the different forks are, this is probably one of the most significant philosophical differences that I can talk about. There are plenty of other differences in features, development processes, and target audiences. But in the end I think this is probably one of the most significant differences.
One of the nice things about having different distributions now, is that we can let people decide on their preferences.
Maybe Jay will follow up with more since he has been working on this stuff :)
one of my biggest pet peeves of MySQL... when I say CREATE TABLE(varchar(255) blah NOT NULL) please do not add your own 'DEFAULT ""' to the end--it is considered by some to be rather rude! I can spot MySQL schema's a mile away by this single trait. Anything NOT NULL almost always has a bullshit default value. Got a NOT NULL int--it will have a DEFAULT 0! Got a NOT NULL date, "DEFAULT 0000-00-00", which isn't even a valid date! How is that for taking your data seriously?
I have always agreed with the above. When we set out to create the "strict" mode within MySQL we could never get agreement on the above sort of problems. Personally I have despised this stuff for over a decade. I know where they come from, aka the limitations of Unireg (the original code), but I have always thought that we should fix this sort of thing (the first time I met Ann Harrison we were both in a room in Germany ranting about how bad this stuff is).
Guess what we did in Drizzle?
We have fixed all of these issues. I go through the manual from time to time to make sure we haven't left any of this stuff in. If we find ones we missed, we fix them.
There was a lot of these sorts of design decisions. The internal conversion system was never really designed around the concept that "some conversions should not happen."
The rule is simple, if the data doesn't fit within the constraint of the type, we need to toss an error, not just "warn" the user.
No "automagic" sorts of conversions.
Always do what the user expects.
No Magic.
No Gotchas.
When people ask me about the differences between the different forks are, this is probably one of the most significant philosophical differences that I can talk about. There are plenty of other differences in features, development processes, and target audiences. But in the end I think this is probably one of the most significant differences.
One of the nice things about having different distributions now, is that we can let people decide on their preferences.
Maybe Jay will follow up with more since he has been working on this stuff :)
(no subject)
from:
obra
date: Mar. 31st, 2009 04:16 pm (UTC)
Link
Reply | Thread
(no subject)
from:
krow
date: Mar. 31st, 2009 04:41 pm (UTC)
Link
This is about storing data. Once it is in the database I believe conversion is just fine. If you are happy with conversion rules for query retrieval then I don't see a reason why we shouldn't allow it.
I just don't want corruption on storage.
Reply | Parent | Thread
Re: Strict Mode and people who don't RTFM
from:
nandix
date: Mar. 31st, 2009 08:57 pm (UTC)
Link
What the slashdot user says, and what a lot of people complain about, is just plain silly.
(S)he doesn't even mention strict mode, and goes on to show how bad MySQL is in handling invalid data and NULL values. This shows a total lack of understanding off the way the product works. If you're going to use something as complex as a DBMS, you should read the manual first. Heck, I even read the manual of a microwave or a TV before it's first use, but most people start using databases as if everything is supposed to work out of the box, and then complain when strange things happens.
If you follow this users' messages on this same slashdot thread, you'll notice (s)he (I'm sorry, I'm not a native English speaker and I can't establish a gender based on the username) also complains that transactions fails miserably if MyISAM tables are involved. Duh?? It's in the cover of the book, you don't use MyISAM if you want ACID functionality, yet there are people out there who do this and then complain when #$# blows up.
You're too kind :)
Reply | Thread
Re: Strict Mode and people who don't RTFM
from:
krow
date: Mar. 31st, 2009 09:02 pm (UTC)
Link
Complaining about MyISAM lacking transactions, is like complaining about the fact that my car has four tires, unlike a motorcycle which is superior because it has two!
"strict mode" is still too permissive though. I am also not a fan of modes in products. I find that it just complicates the hell out of them, and makes testing very hard. I would rather try to do things one way, and get them right for it.
Reply | Parent | Thread