(no subject)
Aug. 6th, 2012 09:59 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
romikchefНу-с, вот и посмотрим, что такое аудитория хабра.
Судя по первой реакции, все труды пропадут втуне, причём из-за очень смешной причины: "Я всё и так знаю, поэтому читать не буду".
Судя по первой реакции, все труды пропадут втуне, причём из-за очень смешной причины: "Я всё и так знаю, поэтому читать не буду".
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-08-07 09:24 am (UTC)С пустым массивом дело тёмное. Сама база пустую конструкцию IN() считает ошибкой. По логике, “x IN()” должен быть всегда равен FALSE, но для того, чтобы это заменить на FALSE, надо парсить запрос до “x”, который может быть каким угодно составным.
О!!!!!!!! Вот только что пришло в голову и проверил. Всё же просто. NULL не равен ничему, в том числе и NULL-у. Поэтому IN() можно безболезненно заменять на IN(NULL) — и это даст FALSE всегда.
Но! Массивы могут встречаться не только в IN, но и в VALUES, например.
no subject
Date: 2012-08-07 09:45 am (UTC)Только почему-то невнятно об этом в комменте написал. Получается, что для массивов в ИН есть аналог интвала, причем - надёжный, в отличие от :)
А вот кстати, не переводить ли и "хелло ворлд" тоже в нулл, а не ноль?
А по поводу VALUES - лично я этот оператор не использую, у меня SET для всего.
Причем, в отличие от Котерова, я не жадничаю, и у меня разные плейсхолдеры для ин и для сет.
А с нуллами при сравнении я имел в виду, что field = NULL не работает как field is NULL (именно поэтому, кстати, IN(NULL) не ищет NULL, я думаю). Но, может, так и лучше?
no subject
Date: 2012-08-07 09:53 am (UTC)С "hello world" в числовом контексте я бы всё-таки делал проверку на is_int/is_numeric и выдавал бы ошибку если что. Ибо нефиг.
no subject
Date: 2012-08-07 10:04 am (UTC)Мне вообще, если честно, не нравится, когда переводят NULL в пыхе в него же в БД. Не могу ничего сформулировать, на уровне ощущений, но - не нравится.
no subject
Date: 2012-08-07 10:36 am (UTC)Я хочу сделать фильтрацию по альбомам, причём предусмотреть и вариант «не входит в альбомы». Вот тебе и NULL в запросе из динамического значения.
no subject
Date: 2012-08-07 11:49 am (UTC)no subject
Date: 2012-08-07 12:13 pm (UTC)no subject
Date: 2012-08-08 10:08 am (UTC)и вот думаю - что делать со скаляром?
руки чешутся превратить его в массив.
что скажешь?
no subject
Date: 2012-08-08 12:43 pm (UTC)no subject
Date: 2012-08-08 12:44 pm (UTC)if (!$data)
{
return NULL;
}
Наверное, правильнее
if (!$data)
{
return 'NULL';
}
?
no subject
Date: 2012-08-08 06:48 pm (UTC)no subject
Date: 2012-08-08 06:43 pm (UTC)Жаль только, что mysql-евской специфики много. А если у меня постгрес?:)
no subject
Date: 2012-08-08 06:46 pm (UTC)"я сам об этом давно думал. Но, во-первых, надо переписывать, поскольку в документации по mysql уже написано, что этот модуль не рекомендуется. А во-вторых, надо аккуратно её выдрать из фреймфорка. Но я, пожалуй, займусь."
Так что будет, чем себя в отпуске занять.
Ну и плюс подумать надо, как это все под ПДО вообще организовывать. ПДО мне кажется более интересным вариантом. Сам по себе. Но и в контексте твоего вопроса тоже :)
no subject
Date: 2012-08-08 06:48 pm (UTC)no subject
Date: 2012-08-08 06:52 pm (UTC)Надо бы сесть, и переписать сначала.
Завтра, после конфы, пожалуй и начну.
no subject
Date: 2012-08-12 01:27 pm (UTC)На деле же откуда-то возникают какие-то мутные зависимости от текущих кодировок, которые я до конца не понимаю. Но если постулировать, что серверная кодировка у нас одна и единственно правильная — UTF-8 — то можно отвязаться от соединения?
no subject
Date: 2012-08-12 02:57 pm (UTC)no subject
Date: 2012-08-12 03:35 pm (UTC)no subject
Date: 2012-08-12 04:16 pm (UTC)Но вот ответ Ильи в 2006 может сойти за пруф:
http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html#c8700