| |
| 2.20, Аноним (-), 19:29, 18/09/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну что, заспорим что ЭТИМ программистам никакой Rust не поможет?
| | |
|
| 1.3, Аноним (-), 10:35, 18/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
Помоему обрезать любые данные для того, чтобы они искуственно вместились в БД это как-то по колхозному. Если не влезает надо всегда генерить эксепшн и чтоб юзер знал, что данные не влезают и их надо бы сократить, а не молча проглатывать а бы что.
| | |
| |
| |
| 3.9, Аноним (-), 11:26, 18/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Ничего плохого в этом не вижу
А вот в том что надо знать хорошо базу которую используешь никогда не сомневался
# cat /etc/my.cnf.d/my.cnf
[mysqld]
sql-mode="NO_BACKSLASH_ESCAPES,STRICT_ALL_TABLES,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
innodb_strict_mode=on
innodb_file_format=Barracuda
innodb_large_prefix=on
Решит все проблемы
| | |
| |
| 4.10, Нанобот (ok), 11:54, 18/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
 >Решит все проблемы
LOL
Да, решит, тут ты, конечно прав. А ещё создаст новые проблемы, и их будет больше, чем было до "решения всех проблем". А если сделать такое на сервере с большим количеством разных баз, то решатор проблем рискует получить физические повреждения от пользователей.
| | |
| 4.21, Аноним (-), 19:35, 18/09/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Решит все проблемы
Странно, проблему беженцев что-то плохо решает. FAIL.
| | |
| |
| 5.27, Аноним (-), 01:14, 19/09/2015 [^] [^^] [^^^] [ответить]
| +/– | |
Вы коммит то смотрели?
Там проверка была вот такая:
my $ret = ($addr =~ /$match/ && $email !~ /\P{ASCII}/ && $email =~ /^$addr_spec$/);
стала вот такая:
$addr =~ /$match/
+ && $email !~ /\P{ASCII}/
+ && $email =~ /^$addr_spec$/
+ && length($email) <= 127)
Вы хоть обпроверяйтесь от забывчивости, невнимательности и просто от того что схема БД может со временем менятся это не спасет. Правильный ответ уметь тюнить базу, чтоб она не обрезала данные если не может по какой либо причине сохранить, лучше пусть SQL error кажет.
| | |
|
|
|
|
| 1.6, Аноним (-), 11:14, 18/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>добавит аккаунт в группы, соответствующие правилам, заданным через регулярные выражения
>регулярные выражения
Повеселили, спасибо.
| | |
| |
| |
| 3.16, йцу (?), 14:44, 18/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
Да тут в общем-то неважно - Perl, PHP или брейнфак. Просто MySQL по-дефолту уж очень "всеяден" и вместо того чтобы ругнуться на попытку вставить слишком длинную строку тупо её обрезает.
| | |
|
| 2.13, SysA (?), 13:41, 18/09/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> На Perl пишут только в Mail.ru и дилетанты!
Ага, то-то в трейдинг- и BI-компаниях дилетантов развелось!.. :)
| | |
|
| 1.15, Ананем кто же еще (?), 14:32, 18/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Mysql какой-то даунский, придумавшему тихенько портить данные вместо генерации ошибки надо оторвать руки. Это уже не первый такого рода баг который я вижу на опеннете, а сколько их еще есть
| | |
| 1.17, Аноним (-), 15:11, 18/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Некоторые пишут что тихое обрезание данных нормально. Только вот потерю введенных данных при таком раскладе можно заметить далеко не сразу. MySQL вообще много где неадекватно себя ведет. И самое странное некоторые подомные мелочи лежат в багтрекере десятилетиями.
| | |
| |
| 2.28, arisu (ok), 05:58, 20/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
 а потому что не надо экономить на DBA. даже стадо хипстеров не заменит одного специалиста.
| | |
|
|
