5 ms·

Personally, I would not use a database which is 'lax' by default instead of 'strict'. What other choices have they made which I need to learn OR it will bite me

Personally, I would not use a database which is 'lax' by default instead of 'strict'. What other choices have they made which I need to learn OR it will bite me big in Production?

zrail 12y ago
Example: Inserting strings into a varchar() that are longer than the limit will silently truncate them. Example: The TIMESTAMP type defaults to the current time instead of null. There are more, but those are the two that have bitten me in the past (and no I do not use MySQL at all if I can help it)
- morgo 12y ago
  See my other comment in this thread RE: string truncation (strict sql mode will default on in MySQL 5.6/5.7). It is possible to change timestamps to default to Null. For backwards compatibility, the previous behavior defaults: http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_explicit_defaults_for_timestamp http://dev.mysql.com/doc/refman/5.7/en/server-system-variabl...
pnathan 12y ago
In a previous life, the lax by default approach of MySQL bit us hard on a regular basis; a number of discrepancies vs. reasonable expectation were had. At the time I left, they were working on migrating toward Postgres, and reports suggest they are extremely happy with pg.
pizza234 12y ago
It's not so easy. MySQL has a large legacy of being used as a very-immediate-although-somewhat-toy database at its roots. For example, in absolute terms, I would find much more troubling the usage of non-transactional tables, justified by meaningless microbenchmarks, which has been somewhat common for some time. Nowadays MySQL is definitely reliable, and it has a much more expert surrounding culture than the past, so if a person/company is willing to put time and knowledge, it's a reasonable choice. I don't find automatic conversion so damaging that people should stay away just because it's default. When you reach some level, you definitely need to have a relatively intimate knowledge of your tools, and at such point, one is far from the "defaults".
- sre_ops 12y ago
  MySQL may have a legacy of crappy code, however it is works quite well. MongoDB has no legacy but a pile of barely working crappy code. https://jira.mongodb.org/browse/PYTHON-532 https://jira.mongodb.org/browse/PYTHON-532
beering 12y ago
You can subtract two DATETIME columns in MySQL and it will not generate any warnings. It will give you an answer that probably is within the ballpark of the actual time difference but isn't the actual time difference.
spitfire 12y ago
If you feed MYSQL an invalid date for a date/timestamp field it will quietly insert 0000-00-00 and produce a warning, not an error.
imron 12y ago
utf8 is not really utf8 and doesn't support 4 byte characters that exist outside the BMP (you'll need the separate utf8mb4 type for that, assuming you're not running on a legacy version that doesn't support that either).

Personally, I would not use a database which is 'lax' by default instead of 'strict'. What other choices have they made which I need to learn OR it will bite me big in Production?

zrail 12y ago

Example: Inserting strings into a varchar() that are longer than the limit will silently truncate them. Example: The TIMESTAMP type defaults to the current time instead of null. There are more, but those are the two that have bitten me in the past (and no I do not use MySQL at all if I can help it)

morgo 12y ago
See my other comment in this thread RE: string truncation (strict sql mode will default on in MySQL 5.6/5.7). It is possible to change timestamps to default to Null. For backwards compatibility, the previous behavior defaults: http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_explicit_defaults_for_timestamp http://dev.mysql.com/doc/refman/5.7/en/server-system-variabl...

pnathan 12y ago

In a previous life, the lax by default approach of MySQL bit us hard on a regular basis; a number of discrepancies vs. reasonable expectation were had. At the time I left, they were working on migrating toward Postgres, and reports suggest they are extremely happy with pg.

pizza234 12y ago

It's not so easy. MySQL has a large legacy of being used as a very-immediate-although-somewhat-toy database at its roots. For example, in absolute terms, I would find much more troubling the usage of non-transactional tables, justified by meaningless microbenchmarks, which has been somewhat common for some time. Nowadays MySQL is definitely reliable, and it has a much more expert surrounding culture than the past, so if a person/company is willing to put time and knowledge, it's a reasonable choice. I don't find automatic conversion so damaging that people should stay away just because it's default. When you reach some level, you definitely need to have a relatively intimate knowledge of your tools, and at such point, one is far from the "defaults".

sre_ops 12y ago
MySQL may have a legacy of crappy code, however it is works quite well. MongoDB has no legacy but a pile of barely working crappy code. https://jira.mongodb.org/browse/PYTHON-532 https://jira.mongodb.org/browse/PYTHON-532

beering 12y ago

You can subtract two DATETIME columns in MySQL and it will not generate any warnings. It will give you an answer that probably is within the ballpark of the actual time difference but isn't the actual time difference.

spitfire 12y ago

If you feed MYSQL an invalid date for a date/timestamp field it will quietly insert 0000-00-00 and produce a warning, not an error.

imron 12y ago

utf8 is not really utf8 and doesn't support 4 byte characters that exist outside the BMP (you'll need the separate utf8mb4 type for that, assuming you're not running on a legacy version that doesn't support that either).