Обожаю линуксоидов! Регулярно дают повод пнуть их. v.5.6.22 Очередной глюк: Если в подзапросе используется переменная, то движок не использует индексы. И не даёт использовать. Код (PHP): set @a = 1; select * from Mans /* force index (primary) */ where eManID = (select 1 from dual where @a) Код (PHP): EXPLAIN Result id select_type table type possible_keys key key_len ref rows Extra 1 PRIMARY Mans ALL (NULL) (NULL) (NULL) (NULL) 1814845 Using where 2 UNCACHEABLE SUBQUERY (NULL) (NULL) (NULL) (NULL) (NULL) (NULL) (NULL) No tables used Добавлено спустя 5 минут 35 секунд: Про глюк LPAD см. здесь: viewtopic.php?f=20&t=48259 PHP, JavaScript, SQL и другой код пишите внутри тегов Код ( (Unknown Language)): [b]php][/b]Тут код[b][/[/b][b]code][/b][/color]
v.5.6.22 Глюк REGEXP (rlike): Код (Text): select '' REGEXP concat('(',field) from table Не выдаёт ошибку регулярного выражения. Всегда будет NULL. Код (Text): select '' REGEXP concat('(','1') from table Выдаёт ошибку.
Win, v 5.6.26 x64 1) LPAD, - баг имеется. 14 месяцев... ( viewtopic.php?f=20&t=48259 ) 2) REGEXP (rlike), - баг имеется. 5 месяцев... (см.выше)
Win, v 5.7.20 x64 1) LPAD, - баг имеется. 41 месяц, 3.5 года. 2) REGEXP (rlike), - баг имеется. 32 месяца, 2.5 года.
Пнём линуксоидов из Oracle ещё раз... Win, v 5.7.20 x64 Эти, эээ, "гении" упорядочивают параметры JSON по их длине. Тест: PHP: select json_object('111', 1, '22', 1, '3', 1) f Результат: Код (Text): {"3": 1, "22": 1, "111": "1"}
И это рассказывается в разделе про индексацию json-полей. Впрочем, тут уже диагноз, удаляюсь из темы.
Не уверен. Но эта "особенность" неправильная, в стиле линуксоидов. Порядок полей в таблице сохраняется, а в JSON-структуре нет. Где логика?
Пнём линуксоидов из Oracle ещё раз... Win, v 5.7.20 x64 Глюк now(), - не округляет микросекунды, просто тупо обрезает. Тест: PHP: select now(6), now(2) --- Добавлено --- И тут попутно возникает вопрос. Время с долями секунды = '00:00:00.7'. При получении времени в секундах сколько должно быть? '00:00:00' или ''00:00:01'? По моей логике - второе.
@Chushkin я подумал, что 00:00:01 - это 10 миллисекунд. Тем более если это одна секунда, то в какой ситуации может быть полезным округлять?
Какая разница, 1 секунда или 0.59? Важен алгоритм. Если время с долями секунды, то правильно округлять, а не отбрасывать. По сути, функции работы со временем должны учитывать точность времени - если целочисленное время (по старому), то как было; если дробное - то округлять до заданной форматом точности.
@Chushkin хз. Вот добавляется у тебя 10 записей в секунду, а время задано с точностью до 1 секунды. В итоге у тебя 16 записей будут выглядеть так Код (Text): 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 00:00:01 // 00:00:00.5 00:00:01 00:00:01 00:00:01 00:00:01 00:00:01 00:00:01 00:00:01 00:00:01 00:00:01 00:00:02 // 00:00:01.5 По-моему это ерунда какая-то...
Ды вот и мне, хоть доку и не читал на эту тему, показалось, что очень уж похоже на индексы табличные. Прям вот 1-в-1. Разве что табличные индексы это shadow-data. Далее, JSON никогда не гарантировал правильный порядок свойств при сериализации-десериализации. Надеяться на это - глупо. Я больше скажу - надеяться на порядок столбцов в таблице тоже глупо. Это прям настолько благодатная почва для неуловимых багов, что оягребу. Хочешь завязать алгоритм на порядок столбцов? Укажи этот порядок явно в запросе.
По логике - правильно. К примеру, если задал с долями секунды (timestamp(1)), при выводе "as is", время будет с десятыми долями. В принципе, сейчас так и есть, за исключением глюка - микросекунды не округляются, а отбрасываются. Если же хочешь результат с меньшей точностью, то нужно округлять. Собственно, как при любой работе с вещественными числами.
Предположим. А что делать с JSON? Вообще, дело не в "надежде", а в удобстве. Всё, что есть в программировании это ради удобства разраба, иначе до сих пор писали бы в машинных кодах. --- Добавлено --- Не знаю, не знаю... Не уверен.
Ну, если мне не изменяет память, то порядок столбцов всё же описывается в стандарте. Хотя, надеяться на это можно с таким же успехом, как и на то что SELECT * FROM table LIMIT 10 отдаст первый 10 записей таблицы, а не первый попавшийся десяток ) А в случае с JSON все так и есть, что бы иметь возможность по нему искать не слишком теряя в скорости, движок его "допиливает" под себя. Вот, раздел доков posgtes по теме, там в общих чертах, но суть ясна.
А если мне не изменяет память, то в самом JS упорядоченность и способ хранения данных в структуре остается на усмотрение конкретной версии конкретного движка. Где-то хранится порядок, в котором данные были внесены, а где-то работает автоматическая сортировка. Это речь именно про реальные объекты в JS. При этом, собсна, при чтении JSON, не важно как он был упорядочен, так как движок все равно имеет свое мнение на этот счет. В данном случае поведение MySQL ни разу не выходит за эти рамки. Задача JSON - донести структуру данных из точки А в точку Б, гарантируя ее корректность. С этим он справляется. Как он будет потом прочитан - уже за пределами его ответственности. Когда ты пишешь что-то в JSON-поле БД, ты не JSON-строку же хранишь. Ты говоришь базе "возьми эту вот структуру и сохрани ее как структуру, а я буду к ней обращаться как к структуре." То есть вот реальный JSON - это то, что ты БД отдал как часть запроса. То, что ты видишь в БД - это уже то, как БД твой JSON прочитала. И хранит она его не как JSON, а как объект. Просто показывает его тебе в удобном для тебя виде. Но делать с этим объектом она уже вольна что угодно. Подразумевается, что это как бы микроБД внутри БД, а не просто поле, в которое ты JSON положил, чтоб потом обратно забрать. Если нужно просто класть в БД JSON и забирать его оттуда "как есть", храни его как строку и не парься, как грицца.