Заметки программиста

Новый метод (очистка мультизапроса) вызвал неожиданные трудности

2011-07-28T02:38:00.000-07:00

Оказалось, что крайне полезный метод clear_multiresult($result), о котором было написано здесь, не работает.

Поиск проблемы был трудный и интересный. Не могу не написать об этом.

Как известно (из документации), метод $mysqli->multi_query() создает в процессе выполнения набор результатов по одному для каждого запроса, входящего в мультизапрос.

Для того, чтобы эти запросы вытаскивать на свет Божий и обрабатывать существуют 3 замечательных метода:

$mysqli->store_result()
$mysqli->next_result()
$mysqli->more_results()

Кому интересны подробности - прошу обратиться к документации.

Скажу только, что загвоздка оказалась в методе $mysqli->next_result().

Предположим, у нас есть мультизапрос, состоящий из 4-х запросов. Причем в третьем запросе ошибка. Тогда мы будем действовать следующим образом.

Выполним $mysqli->store_result(). Этим мы вытащим из недр API результат первого запроса.
Обработали результат и удалили его.
Выполняем подготовку второго запроса методом $mysqli->next_result(). При этом метод вернет TRUE, что и ожидалось.
Выполним $mysqli->store_result(). Этим мы вытащим из недр API результат второго запроса.
Обработали результат и удалили его.
Выполняем подготовку третьего запроса методом $mysqli->next_result(). При этом метод вернет FALSE, что абсолютно не ожидалось. При этом в документации черным по белому написано, что метод возвращает истину, если метод выполнился удачно, и ложь, если операция потерпела неудачу. Какая же тут неудача? Все вполне удачно, поскольку если не обращать внимания на возвращаемое значение метода, ошибочный результат все-таки подготавливается и можно двигаться дальше, то есть проверять на ошибки и тд и тп.
Не обращаем внимания на возвращаемое значение и выполняем $mysqli->store_result(). Этим мы вытащим из недр API результат второго запроса.
Обработали результат, то есть проверили его на ошибки, выявили ошибку и выполнили my_exit();

А как же проверять тот факт, что результаты кончились? Конечно методом $mysqli->more_results(). Он для этого и создан.

Новый метод в классе EMYSQL

2011-07-12T04:17:00.000-07:00

Класс EMYSQL позволяет выполнять мультизапросы. Это такая строка, которая состоит из нескольких запросов MYSQL, разделенными точкой с запятой.
После такого запроса в недрах MySQL рождается результат, состоящий из результатов каждого запроса, входящего в мультизапрос. Даже если мультизапрос состоял из запросов, которые не должны возвращать результат, результат все равно будет не пуст. Нужно очистить этот результат, обратившись к каждому результату по отдельности.
Добавлен метод clear_multiresult($result), который очищает результат мультизапроса, точнее все результаты запросов, входящих в мультизапрос.

Временная таблица имен файлов для парсинга

2011-07-12T00:06:00.000-07:00

CREATE TABLE IF NOT EXISTS `tbl_parsefile` (
  `parsefile_id` int(6) NOT NULL AUTO_INCREMENT COMMENT 'Первичный ключ',
  `parsefile_file` varchar(250) NOT NULL DEFAULT '' COMMENT 'Имя файла с путем',
  `parsefile_code` tinyint(2) NOT NULL DEFAULT '0' COMMENT 'Числовая категория файла',
  `parsefile_tcode` varchar(20) NOT NULL COMMENT 'Текстовая категория файла',
  PRIMARY KEY (`parsefile_id`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 COMMENT='Временная таблица файлов для парсинга' AUTO_INCREMENT=1 ;

Коды:
1 (SS_TABUPLOAD::PACKAGE_PAGE) - файл проекта. tcode - название проекта
2 (SS_TABUPLOAD::FILE_PAGE) - файл файла проекта. tcode - название файла

Таблица для учета подпроектов (категорий)

2011-07-11T23:53:00.000-07:00

--
-- Структура таблицы `tbl_subpack`
--

CREATE TABLE IF NOT EXISTS `tbl_subpack` (
`subpack_id` int(6) NOT NULL AUTO_INCREMENT COMMENT 'Первичный ключ',
`subpack_pack` int(6) NOT NULL COMMENT 'Ссылка на package',
`subpack_name` varchar(30) NOT NULL DEFAULT '' COMMENT 'Название категории',
`subpack_longdescr` text NOT NULL COMMENT 'Длинное описание категории',
PRIMARY KEY (`subpack_id`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 COMMENT='Категории каждого проекта' AUTO_INCREMENT=1 ;

Таблица для учета проектов

2011-07-11T23:50:00.000-07:00

--
-- Структура таблицы `tbl_pack`
--

CREATE TABLE IF NOT EXISTS `tbl_pack` (
`pack_id` int(6) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Первичный ключ',
`pack_name` varchar(50) NOT NULL COMMENT 'Название проекта (documentor)',
`pack_descr` varchar(50) NOT NULL COMMENT 'Более длинное название проекта (русский язык)',
`pack_npp` int(6) unsigned NOT NULL DEFAULT '0' COMMENT 'Номер для сортировки (для будущих версий)',
`pack_longdescr` text NOT NULL COMMENT 'Длинное HTML описание проекта',
PRIMARY KEY (`pack_id`),
KEY `pack_npp` (`pack_npp`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 COMMENT='Проекты php (packages)' AUTO_INCREMENT=5 ;

Изменения в плане обработки ошибочных ситуаций

2011-07-11T22:50:00.000-07:00

При здравом взгляде, оказалось, что практически все ошибки, который возникают в классах EMYSQL, HUP и CRYPT являются фатальными и нет никакого смысла при их возникновении продолжать работу скрипта. Поэтому вместо того, чтобы запоминать код ошибки в свойстве $err_no, громное большинство таких ошибок заменены на вызов функции my_exit().

Новое свойство $hup_common в классе BASE_CHECK

2011-07-10T00:57:00.000-07:00

Введено новое $hup_common свойство в классе BASE_CHECK.
Изменен текст метода set_unexpected() в классе BASE_CHECK.

Подробности здесь.

Проблемка в проекте check

2011-07-10T00:18:00.000-07:00

Следующая проблемка возникла в проекте check.
Дело в том, что сам по себе проект check не работает с базой данных. Это ему как бы не нужно. Он просто проверяет и преобразует к безопасному виду все параметры, получаемые страницей. Но в проекте, а это целая гроздь классов, работающих совместно, есть, все-таки, одна паршивая овца, которая использует базу данных. Это класс UNEXPECTED_DATA, который записывает все события по появлению во входных параметрах неожиданных данных в базу данных.

В свою очередь класс UNEXPECTED_DATA создан на основе класса TBASE_EMYSQL и поэтому ему нужен для работы с базой данных номер хупа. Номер этот ему взять неоткуда, поскольку сам класс UNEXPECTED_DATA является служебным, вызывается из недр проекта и задать ему номер хупа мы можем только через процесс переопределения метода set_unexpected() класса BASE_CHECK или его наследника. С другой стороны, городить для такой пустяковой задачи, как задание номера хупа, целый метод - просто не хочется. Кроме того, нам придется городить новый класс CHECK (наследник BASE_CHECK) для каждого нового хупа. Это не правильно!

В связи с этим делаем специальное свойство, которое будет принадлежать классу BASE_CHECK и будет содержать номер хупа. По умолчанию это будет единица. Эту единицу можно будет поменять на что угодно сразу после строчки создания объекта наследника класса BASE_CHECK, назовем его SOME_CHECK.

Назовем это свойство ... ну не знаю .... $hup_common, например. По возможности будем использовать это имя для всех свойств, содержащих номер хупа общий для проекта (грозди) классов.

Идея с включением волшебных констант не сработала

2011-07-09T23:55:00.000-07:00

Идея с включением волшебных констант не сработала!

Поспешил я с ней! Думать иногда надо! Константы выдаются правильно. Так, например, константа __FILE__ когда происходит ошибка всегда содержит значение "DEBUG.php"

И я ведь уже наступал на эти грабли и не раз!!!

Дополнения в выводе отладочной информации

2011-06-28T21:57:00.000-07:00

В вывод отладочной информации любого уровня введен вывод волшебных констант:

__FILE__
__CLASS__
__LINE__
__FUNCTION__
__METHOD__

Изменения можно будет увидеть в исходном коде после очередного обновления документации

Создание класса MY_DEBUG и строгая функция my_exit_strict()

2011-06-28T00:38:00.000-07:00

Появилась необходимость в создании функции my_exit_strict(), которая гарантированно не выводила бы информацию на экран ни в каком случае.

Для этого в файле DEBUG.php был создан небольшой сервисный класс MY_DEBUG. Все функции модуля стали использовать этот класс для своей работы.

Старые проекты переделывать не нужно.

Класс обновится в разделе документации после очередного обновления

Изменение вывода отладочной информации

2011-06-28T00:33:00.000-07:00

Когда по той или иной причине не срабатывает хуп, класс NEW_EMYSQL или по какой-нибудь еще, у нас вылетает сообщение "Не смогли соединиться с базой такой-то" и все.

Для отладки этого мало.

В метод open_bases($hup) было внесено изменение, при котором выводится вся инфа по подключенной базе данных, включая пароль.

Это секретная информация. Чтобы она не попала в чужие руки, были внесены изменения в модуль DEBUG. Была в частности сделана дополнительная функция my_exit_strict(), которая гарантированно не выводит отладочную информацию на экран.

Изменения в документации будут отражены после очередного обновления.

Выполнение мультизапроса с очисткой результатов

2011-06-24T03:03:00.000-07:00

Этот фрагмент кода выполняется в классе - наследнике TBASE_EMYSQL

Код:

<?php
$result = $this->link_id->multi_query ($cSql);
if ($result) {    // Проверим все результаты операций
   $count = 1;    // Счетчик запросов
   do {                    
      /* Запомним очередной */
      $result = $this->link_id->store_result();
      /* Нас интересуют только ошибки и
        уничтожение результатов */
      if (! $result) {
          /* Даже в этом случае запрос мог
             выполниться без ошибок.
             Просто результата могло не быть.
             Надо проверить дополнительно */
          if ($this->link_id->errno > 0) {
              my_exit('',"Ошибка в запросе # $count!<br>$cSql<br>{$this->link_id->error}");    
          }
       } else {
          $affected = $this->link_id->affected_rows ;
          $result->close();   // Если ошибок не было - уничтожим запрос
       }
       $count++;
    } while ($this->link_id->next_result());
                
} else {
   my_exit('',"Ошибка в запросе № 1!<br>$cSql<br>{$this->link_id->error}");    
}
?>

Очередное обновление документации

2011-06-24T01:17:00.000-07:00

Произошло очередное обновление документации классов

Добавлен класс CYR_UTF8
Начал реорганизацию проектов, как предполагал ранее. К счастью, родительские классы, принадлежащие другими проектами не пропали. С другой стороны индексные страницы стали меньше по весу и размеру.

Похоже, реорганизацию следует продолжать.

Конвертер UTF-8 <-> WIN-1251

2011-06-24T00:30:00.000-07:00

При желании сконвертировать текст из UTF-8 в win-1251 обычно сталкиваешься с трудностями. Пришлось сделать свой конвертер, и в процессе его производства выяснились некоторые причины трудностей конвертирования. В качестве предисловия хочу изложить эти причины, поскольку они довольно прикольные.

Судите сами.

Известен состав кодировки win-1251. Ее можно посмотреть здесь:http://ru.wikipedia.org/wiki/Windows-1251.

В UTF-8 за кириллицей закреплено пространство кодов с 0x400 по 0x4FF. (http://www.utf8-chartable.de/unicode-utf8-table.pl).

При анализе этих двух замечательных таблиц можно сделать следующие выводы.

Русские буквы с "А" до "я" идут одним куском как в одной кодировке, так и в другой. Это хорошо, поскольку мы можем не проверять символы побайтно, а пользоваться диапазоном адресов. Но вот неудача!
Буквы "Ё" и "ё" идут совершенно отдельно. Их придется и обрабатывать отдельно.
Других более или менее полезных символов в кириллической части кодировок нет. Только один. Знак номера "№". И вот тут долгожданный прикол. Этого символа НЕТ в кириллической части UTF-8. Он совсем в другом месте - в разделе редких знаков пунктуации и кодируется 3-мя байтами.

Вот это сюрприз из сюрпризов (в последнем пункте), ибо либо мы не заморачиваемся на знак номера, либо конвертер у нас здорово усложняется, поскольку нам придется не ограничиваться теми символами, которые кодируются одним и двумя символами, но рассматривать так же возможность появления в нашем тексте трех-байтных знаков. Ну а где 3 там и 4. Так что из-за одного символа пришлось делать полный конвертер со всеми возможными проверками, поскольку плевать на такой хороший знак мне не хотелось.

tutorial в PHPDocumentor

2011-06-23T02:20:00.000-07:00

Посмотрел я еще раз на свою документацию и обратил внимание на то, что в качестве описания проектов всегда на странице возникает один и тот же текст. А мне напротив, хотелось бы сделать описание каждого проекта. Как это сделать - загадка.

Я иду на форум PHPDocumentor и нахожу там вопрос какого-то иностранного чувака именно про то, что мне нужно. В ответ ему было сказано, что для реализации подобных вещей в PHPDocumentor служит механизм tutorial. Этот механизм называется еще "подключаемой документацией". Суть не буду подробно описывать. Для этого поста важно только то, что документация эта должна быть написана в формате DocBook.
Короче говоря, сделал я так, как написано в документации, обозвал файлы так, как нужно, написал в них текст такой, какой нужно. Все подключилось, но вместо русского текста - знаки вопроса. После недолгих поисков выяснилось, что формат DocBook является по сути подмножеством XML и, судя по всему, ожидается в кодировке UTF-8.
Тогда я поставил в свою подключаемую документацию первой строчкой следующее:

И ничего не изменилось!
Тогда я свою документацию в UTF-8 И тоже ничего не изменилось!
Тогда я опять полез в интернет и нарыл там инструкцию, которая позволяет документору правильно работать с UTF-8. Вот эта инструкция:

Вот так.Зашел я в означенный файл. А там все прозрачно так, что просто жуть. Буквально следующее:

Взять содержимое файла в строку.
Если в файле есть строчка utf-8 в любом регистре, то конвертировать весь файл, точнее всю строку функцией utf8_decode().
Парсить дальше преобразованный файл.

С функцией utf8_decode() следующая история, и я уже накалывался на нее не один раз. Эта функция не преобразует текст из UTF-8 в 1251. Она, типа, чисто юниксовая и работает с чисто юниксовыми кириллическими кодировками, а именно ISO-8859-1.
Но я сделал некоторые полезные выводы.

Инструкция неизвестного программиста, приведенная выше - не точная и лучше ей не пользоваться
Для того, чтобы конвертировать поступающий на обработку DocBook нужно всего навсего поставить в его начале строку <?xml version="1.0" encoding="utf-8"?>
Нужно влепить туда правильный конвертер из UTF-8 в 1251.
Конвертер у меня уже есть.

Так что я долго не мучился и изменил код на следующий:

                  if (stristr($ret, "utf-8") !== "")
                     {
                     include ('class.CYR_UTF8.php');
                     $utf8 = new CYR_UTF8();
                     $ret = $utf8->to_win($ret);
                     }

И все заработало! Ура! Я крут!

Обновление документации

2011-06-17T04:43:00.000-07:00

Добавлено навалом новых классов.Кстати говоря, возникло желание разделить документацию классов по проектам. Не стоит кидать все классы в проект php-classes, который даже не имеет никакой смысловой нагрузки. Однако, раскидывание классов по проектам довольно сложная задача, особенно потому, что классы здорово переплетаются.

Приколы с тегами и сущностями

2011-05-06T02:06:00.000-07:00

Этот текст олицетворяет этап освоения PHP. Надо искать более зрелые подходы на этом блоге. Но и этот почитать иногда интересно.

Казалось бы, все специалисты знают, что такое HTML. В этой статье мне важно только то, что HTML является текстом, в котором есть теги.

Что такое тег? Тег это строка, заключенная в угловые скобки. Например: <a> - тег. При этом между левой угловой скобкой (знак меньше) и словом "a" не должно быть пробела. Если он есть, то это уже не будет тегом! Это будет символ "меньше" за которым следует некая строка.

Пробуем. < a> - нифига не тег! Показывается как три символа!

Из этого супер-упражнения следует без сарказма важнейший итог - для того, чтобы испортить HTML код, нужно испортить в нем всего один символ, и этот символ "<".

Это важнейшее свойство тегов надо запомнить. Кстати, а почему, интересно, при определении тега редкий писатель указывает на то, что между открывающейся угловой скобкой и названием тега не должно быть пробела? Или это само собой разумеется?

Часто бывает необходимо показать на странице тег не как тег, акак текст. Для этого вместо служебных символов в явном виде мы можемуказать их html-сущности. Вполне понятно и логично, что браузером преобразовываются все html-сущности вне зависимости от того, что мы хотели показать - тег или отдельный символ.

Прикол может возникнуть при выводе текста для редактирования в форму ввода, например, в поле textarea. Представим себе, что мы храним статью (ее исходный html код) в базе данных. Причем статья содержит символы, закодированные их html_сущностями. В поле при редактировании мы видим не html сущности, а реальные символы. Получается, что поле тоже преобразовывает сущности в символы. Следовательно, при сохранении этого текста без изменений, мы записываем в базу данных реальный не измененный html-код.

Что делать? Либо надо конвертировать сущности перед записью в базу данных, либо надо конвертировать амперсенды перед редактированием текста. Тут уже нам предоставляется выбор - в каком виде нам удобнее редактировать - в виде сущностей или в виде кода

Здесь нас поджидают следующие приколы. Предположим, мы хотим отредактировать текст в виде html, то есть редактировать угловые скобки как скобки, а не как сущности (и т.д.). И в этот текст мы вручную вставляем вставляем html-сущность. Например, двойную кавычку. После редактирования и перед сохранением мы преобразовываем все символы в сущности. При этом символ амперсенда в сущности двойной кавычки тоже преобразуется. Теперь мы считываем этот текст из поля базы данных и пытаемся вывести его на экран. Все прекрасно выводится, только кавычка видна не как кавычка, а как сущность. Вот в этом-то и прикол. Если мы редактируем теги без сущностей, то и кавычки мы должны указать в виде кавычек. Но при этом все кавычки без исключения преобразуются в сущности, а не те, которые нам надо.

Тут мы чувствуем, что теряем контроль над текстом, который редактируем и говорим себе, что Бог с ним с удобством, будем редактировать текст с сущностями. Конечно, редактировать текст с сущностями - чистый ужас, но зато мы получаем контроль над всеми символами без исключения. Те символы, которые мы хотим получать в виде символов будут получаться в виде символов, а те, которые мы хотим получать в виде сущностей - будем получать в виде сущностей (храниться они будут в виде дважды закодированных сущностей). Напомню, что мы добились этого тем, что преобразовали символы в тексте в сущности перед редактированием, а после редактирования ничего не преобразовывали.

Второй способ

Можно закодировать все или некоторые служебные символы чем-нибудь другим при кодировании текста перед сохранением в базе данных. Причем для каждого html-символа мы придумываем некую уникальную и ни на что не похожую замену. Чтобы не получилось так, что кодируем символы с использованием амперсенда, а амперсенд может быть закодирован. И так до бесконечности. При кодировании символов уникальными строками мы получаем интересный эффект.Мы можем кодировать один и тот же текст сколько угодно раз. При этом закодируется он только один раз, а все остальные разы останется неизменным, поскольку в нем не останется символов, которые можно закодировать. Если в закодированный текст был добавлен html-текст, то для приведения текста к закодированному виду его нужно просто еще раз закодировать. Более осмысленными становятся действия программиста при хранении закодированного текста. Перед записью текста - кодируем. Перед выводом на экран - раскодируем.

Для реализации этого альтернативного кодирования и был создан класс HTML_CONV. Класс этот сделан был давно, когда я только начал осваивать php и программирование сайтов. Сейчас, когда я стал уже более зрелым программистом, я вижу и слабые места этого подхода и вообще его незрелость. Об этом я напишу в другом посте. А этот пост пусть будет памятником моих этапов освоения php.

Структура массива ХУПов для класса EMYSQL

2011-05-05T02:27:00.000-07:00

ХУП - одно из основных понятий этого проекта. ХУПом я назвал комплект из четырех строк, наличие которых необходимо для подключения базы MySQL. Это Хост, Юзер, Имя БД, Пароль. Именно в такой последовательности. С точки зрения программиста - один ХУП это массив из четырех строк.

Перед записью в файл, ХУПы преобразовываются в текстовый вид. При этом один ХУП должен располагаться в одну строку и его компоненты разделены строкой разделителем. Важно! Не символом разделителем, а строкой разделителем! Компоненты ХУПа при записи в файл сохраняют указанную последовательность.

Файл ХУПов содержит несколько ХУПов. Как создается такой файл:

Каждому ХУПу для локального хоста должен соответствовать ХУП для удаленного хоста.
Для "локальных" ХУПов строка хоста имеет значение 'localhost'.
Можно указать ХУПы для локального хоста, а потом ровно столько же ХУПов для удаленного. Можно их указывать вперемежку. Важно только порядок следования ХУПов. Второй ХУП для локального хоста должен соответствовать второму ХУПу для удаленного.
ХУПы записываются по одному на строке либо с разделителем \r\n
То, что получилось, шифруется и записывается в файл ХУПов. В итоге получается не текстовый, а вполне себе бинарный файл.

Создать массив ХУПов вручную практически не возможно из-за огромной трудоемкости процесса. Для этой цели на сайте написан и действует интерактивный инструмент. Я сам им пользуюсь.

И напоследок несколько напоминалок.
Зашли в указанный конструктор ХУПов после длительного промежутка времени и в который раз возникает вопрос:
Вопрос. Что за разделитель? Это разделитель сведений внутри ХУПа или самих ХУПов?
Ответ. Это разделитель сведений внутри ХУПа. Сами ХУПы разделяются символом новой строки, то есть просто записываются на отдельных строках.

Вопрос. А что, если у меня только одно подключение к базе данных? И вообще, разве это не самый обычный и популярный вариант работы?
Ответ. Если нужно всего одно подключение к базе данных, в файле ХУПов должно быть указано 2 ХУПа. Одно для подключения к базе данных на удаленном хосте, а второе для того же подключения, но на локальном хосте. Помним, что грамотный сайт использует разных юзеров с одной и той же базой данных. У каждого пользователя свои полномочия. Для каждого юзера составляется отдельная пара ХУПов.

Вопрос. А если мне не нужен ХУП для удаленного хоста? Что если я только начал делать сайт и еще не зарегистрировал хостинг?
Ответ. Используем одинаковые ХУПы для удаленного и локального хоста. ХУПы могут быть только парные. После регистрации сайта и выбора хостинга переделываем файл ХУПов.

Вопрос. Блин! Так ничего и не понял. Что записывать в окошко ХУПов в конструкторе?

Ответ. Предположим, у нас есть удаленный хостинг.

Адрес MYSQL сервера: mysql-tru-lala.ru:3306;
Пользователь oy_lala_user;
Имя базы данных oy_lala_main;
Пароль: akljhfas.

На локальном хосте мы сделали следующие настройки:

Адрес хоста: localhost;
Пользователь ss;
Имя базы данных ss;
Пароль: 123456

В поле разделителя мы вводим строку ##

В поле ХУПов мы записываем следующий текст:

mysql-tru-lala.ru:3306##oy_lala_user##oy_lala_main##akljhfas

localhost##ss##ss##123456

Все!

Вопрос. Как класс EMYSQL понимает, какие ХУПы надо использовать - локальные или удаленные?

Ответ. В папку сайта на локальном хосте мы записываем специальный пустой (или не пустой) файл с конкретным названием. Присутствие этого файла на сайте и свидетельствует о том, что сайт на локальном хосте работает. Название файла с путем от корня вводится в конструкторе в специальное поле.

Задержка в реализации самодельного блога

2011-05-04T23:03:00.000-07:00

К сожалению, нет времени на программирование самодельного блога. Нет времени даже на документирование существующей системы классов! На работе жуткий прессинг со стороны начальства.

В связи с этим принимаю решение вести блог проекта документации в этом самом блоггере. Существующий блог в том виде, в каком он существует (по адресу http://docphp.ru), можно использовать для подготовки записей для блоггера.

Как проверить дату PHP на пустое значение

2011-03-23T04:57:00.000-07:00

Пустая дата в PHP - 1970-01-01 00:00:00 GMT
Чтобы проверить дату на это значение можно сделать так:

if (strtotime ($time) <= 0 ) {
echo 'Пустая дата';
}

Нужно обязательно проверять на отрицательные значения, поскольку момент в времени 1970-01-01 00:00:00 по Москве (например) до наступления начала эпохи UNIX еще целых 3 часа. Таким образом функция вернет -10800

Возможно, на разных операционных системах поведение функции strtotime() будет разное. По крайней мере так в документации написано, а я не проверял.

Сравнение дат в MYSQL запросах

2011-03-22T05:37:00.000-07:00

Предположим, у нас есть поле со значением date_time. По нему установлен индекс. Тогда мы можем найти все записи от определенного числа разными способами. Однако, нужно иметь ввиду следующее.

Только поиск вот таким запросом (ищем все записи от 2009-04-02)

SELECT * FROM `tbl_diary` WHERE `diary_date` >= '2009-04-02' and `diary_date` < '2009-04-03'
или
SELECT * FROM `tbl_diary` WHERE `diary_date` >= '2009-04-02 00:00' and `diary_date` <= '2009-04-02 23:59'

использует индекс по полю datetime. Если мы будем использовать вычисляемые значения даты, то поиск будет проходить перебором и индекс использоваться не будет.

Кстати, второй запрос может быть намного удобнее для программирования

Например,

SELECT * FROM `tbl_diary` WHERE DATE_FORMAT(`diary_date`,"%Y-%m-%d") = '2009-04-02'

не ищет по индексу, а перебирает все строки подряд.

То же самое с запросом типа

SELECT * FROM `tbl_diary` WHERE UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(`diary_date`) < 86400

Ярлыки по умолчанию

2011-03-16T02:51:00.000-07:00

Как можно догадаться, я делаю блог не просто так, а потому, что меня кое что не устраивает в блогах стандартных. В частности мне бы хотелось иметь так называемые "ярлыки по умолчанию". Другими словами, если я делаю запись, то у нее уже должен быть ярлык. Для этой цели у меня есть в базе данных следующие, подходящие для этой цели, поля:

Поле наименования записи блога
Поле имени файла

Значения этих полей можно сразу можно использовать в качестве ярлыков. Сложность в том, что для разных типов записей использовать эти записи для создания ярлыков нужно по-разному.

Поле класса актуально только для частей класса - методов, свойств, констант и т.д.
Поле имени файла актуально для класса и модуля, а через них и для их членов.

Похоже, пришла пора разобраться с типами записей и алгоритмом учета каждого типа.

Класс для управления ярлыками

2011-03-16T01:40:00.000-07:00

Класс управления ярлыками

Преамбула:

Следующий класс логически представляет ярлыки и их связи с блогом. Возможно, нужно сразу разделить эти функции. Ярлыки к ярлыкам, а связи к связям. Возможно, для связей нужно свой класс делать. Но это будет после. А пока этот класс даже не отлажен. В нем наверняка могут быть ошибки.

На сегодняшний день класс умеет проверять существование ярлыка и связи ярлык-блог и добавлять ярлык и связь.

Пример:

<?php
/**
 * Класс для работы с тегами блога. Логически класс представляет список всех возможных тегов и операции с ними
 * 
 * Кстати, пример использования класса <b>TBASE_EMYSQL</b>
 *
 * @author Полуэкт
 * @package BLOG
 * @see TBASE_EMYSQL
 */
include_once ('class.TBASE_EMYSQL.php');

/**
 * Класс для работы с тегами блога. Логически класс представляет список всех возможных тегов и операции с ними
 *
 * Кстати, пример использования класса <b>TBASE_EMYSQL</b>
 *
 * @author Полуэкт
 * @package BLOG
 * @see TBASE_EMYSQL
 */
class SS_BLOGTAG extends TBASE_EMYSQL {
    var $blogrec_id;   // активная запись блога

//------------------------------------------------------------------------------------------------------------
    /**
     * Поиск записи в таблице ярлыков по тексту ярлыка
     *
     * Используется для недопущения дублирования ярлыков. Текст ярлыка не должен содержать опасных
     * символов. (за это обычно отвечает класс <b>CHECK</b>)
     * 
     * @param String $tag_text - текст (содержание) искомого ярлыка
     * @return Integer - первичный ключ найденной записи или 0
     */
    function find_tag($tag_text) {
        if (empty($tag_text)) {
            return 0;
        }
        $query = 'SELECT `tag_id` FROM `tbl_tag` WHERE `tag_text` = "'.$tag_text.'"';
        $result = $this->link_id->query($query) or
                my_exit('', "Ошибка в запросе поиска ярлыка <br>$query<br>{$this->link_id->error}");
        if ($result->num_rows > 0) {
            $row = mysql_fetch_assoc($result);
            return $row['tag_id'];
        }
        return 0;
    }
    //------------------------------------------------------------------------------------------------------------
    /**
     * Проверить, связан ли определенный ярлык с определенной записью блога
     * 
     * @param Integer $tag_id - ид ярлыка, привязку которого надо проверить
     * @param Integer $blog_id - если передан, то проверяется привязка к нему, если нет, то
     * к активной записи класса 
     * 
     */
    function tag_is_linked($tag_id, $blog_id = 0) {
        if (empty($blog_id)) {
            $blog_id = $this->blogrec_id;
        }
        if (empty($blog_id) or empty($tag_id)) { my_exit('','При поиске связки блог - ярлык один из параметров пуст!'); }
        return ! empty ($this->mysql->count_records_sql('SELECT COUNT(*) FROM tbl_tagblog WHERE tagblog_tag ='.$tag_id.' and tagblog_blog ='.$blog_id) );
    }
    //------------------------------------------------------------------------------------------------------------
    /**
     * Добавить один ярлык в справочник ярлыков и соединить его с текущей записью
     *
     * Первичный ключ ярлыка - автоинкрементарный, а текст ярлыка должен находиться в $_REQUEST['tag_text']
     * Ключ поста совпадает с названием поля.
     *
     * @return Boolean - истина, если запись добавлялась, ложь, если нет
     */
    function add_tag() {
        if (empty($_REQUEST['tag_text'])) { return false; }

        $duplicate = $this->find_tag($_REQUEST['tag_text']);
        if ( $duplicate == 0) { 
            // Добавляем ярлык
            $query = 'INSERT INTO `tbl_tag` SET `tag_text` = "'.$this->link_id->real_escape_string($_REQUEST['tag_text']).'"';
            $result = $this->link_id->query($query) or
                    my_exit('', "Ошибка в запросе добавления ярлыка <br>$query<br>{$this->link_id->error}");
            $tag_id = $this->mysql->select_sql('SELECT LAST_INSERT_ID()');        
        } else {
            $tag_id = $duplicate;
        }
        // Если установлена активная запись, привяжем к ней только что созданный ярлык
        if (!empty($this->blogrec_id)) {  //
            if (! $this->tag_is_linked($tag_id)) {  // Надо привязывать. Пока не привязано
                $this->add_link($tag_id, $blog_id);
            }
        }

    }
    //------------------------------------------------------------------------------------------------------------
    /**
     * Добавить связку "ярлык - блог"
     *
     * Никаких проверок не производится. Только добавление
     * 
     * @return Integer Количество затронутых рядов при добавлении связи
     */
    private function add_link($tag_id, $blog_id) {

        $query = 'INSERT INTO `tbl_tagblog`
            SET `tagblog_tag` = "'.$tag_id.'",
                `tagblog_blog` = "'.$blog_id.'"';
        $result = $this->link_id->query($query) or
                my_exit('', "Ошибка в запросе добавления связки ярлыка и блога<br>$query<br>{$this->link_id->error}");
        return $this->link_id->affected_rows;
    }

//------------------------------------------------------------------------------------------------------------
}
?>

Таблица связей между ярлыками и записями блога

2011-03-15T23:13:00.001-07:00

CREATE  TABLE  `classes`.`tbl_tagblog` ( `tagblog_tag` INT( 10  )  UNSIGNED NOT  NULL  COMMENT  'Ссылка на ярлык',
 `tagblog_blog` INT( 11  )  UNSIGNED NOT  NULL  COMMENT  'Ссылка на запись блога',
 INDEX (  `tagblog_tag` ,  `tagblog_blog`  ) 
) ENGINE  =  MYISAM  COMMENT  =  'Связь таблиц ярылыков и записей блога';