Имеем такую ситуацию: есть бд mysql, все таблицы этой бд в кодировке latin1, текст внутри этих таблиц засунут в кодировке cp1251. Цель: конвертировать таблицы и данные в них в utf8.

КОРОТКО И ВНЯТНО

mysqldump -u user -p --default-character-set=latin1 --set-charset db_name > dump_db.sql
iconv -f cp1251 -t utf8 dump_db.sql > dump_db_utf.sql

Затем заменить в конвертированном дампе кодировку latin1 на utf8 вручную.

ДЛИННО И ВДУМЧИВО
Понадобится: консоль, screen, iconv, vim(другой ваш любимый редактор) и mysql c mysqldump конечно.

Делаем дамп исходной базы обычным образом (чтобы не корячить боевую)

mysqldump -u user -p db_name > dump.sql

Создаем в mysql базу для того чтобы над ней измываться и заливаем туда наш дамп

mysql -u user -p
# ввели пароль, зашли
CREATE DATABASE db1;
# выходим из mysql ^D
mysql -u user -p db1 < dump.sql
# ввели пароль

Итого имеем тоже самое в нашей тестовой базе. Теперь чтобы понять суть проблемы сделаем так: переведем кодировку в screen в cp1251 и заглянем в бд чтобы увидеть русский.

# переводим кодировку консоли в screen (или вашим способом)
^a:encoding cp1251
# идем в mysql
mysql -u user -p
# переключаемся на кодировку нашей бд
set names latin1;
use db1;
# выбираем поле в котором ожидаем русский язык
select field from table_name limit 1;

Если русский увидели то все ок. Дальше все понятно. mysqldump умеет выгружать данные с установленным чарсетом, делается это вот так

mysqldump -u user -p --default-character-set=latin1 --set-charset db1 > dump_db1.sql

То есть выводим содержимое в файл так же как мы смотрели выше через mysql, установив кодировку исходной БД. Теперь открываем наш дамп в vim. Учитывая что кодировка консоли у нас сейчас тоже выставлена в cp1251 - должны увидеть в дампе русский текст. Выходим из редактора и конвертируем дамп

iconv -f cp1251 -t utf8 dump_db1.sql > dump_db1_utf.sql

Теперь меняем кодировку консоли обратно в utf8

# для screen
^a:encoding utf8

Открываем наш дамп в utf8 и правим кодировки latin1 на utf8

vim dump_db1_utf.sql
# замена с подтверждением для vim
:%s/CHARSET=latin1/CHARSET=utf8/gc

Ещё в начале дампа надо будет изменить строку вида

/*!40101 SET NAMES latin1 */;

На вот такую

/*!40101 SET NAMES utf8 */;

Все, имеем дамп в utf8. По аналогии немного повращав мозгами можно справляться с другими подобными заморочками.

Вообще элементарная штука, но полезная, можно прикрутить что-то при необходимости. Суть простая - читаем результат какой-то команды выполненной в консоли и вставляем его в текущий открытый файл и положение курсора в этом файле соответственно.
В виме смотрим короткое описание :h read + помним что выполнение внешней команды в виме начинается с восклицательного знака :!ls -1
Итого имеем вот такие примеры использования

:r!ls -l1
:r!fortune
:r!df -H
:r!date +\%F_\%H_\%M

С учетом того что команды мы можем повесить на выбранные хоткеи или их последовательности/комбинации, то возможность на мой взгляд достаточно интересная.

Столкнулся с багой оригинального характера. Когда написал свою первую прокладку под mysql сильно радовался тому, что все работает и довольно привычно-удобно. Но оказывается я страшный лошара. В этой самой прокладке есть метод foundRows который должен возвращать (и это иногда работает!) количество рядов в запросе без учета LIMIT (см. FOUND_ROWS()). Загвоздка в том что FOUND_ROWS() сработает только для того запроса который был перед ним в пределах одного коннекта. То есть сначала запрос на select с лимитом и следующим обязательно должен быть select found_rows() примерно так

SELECT SQL_CALC_FOUND_ROWS * 
FROM tbl_name
WHERE id > 100 
LIMIT 10;

SELECT FOUND_ROWS();

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

SELECT SQL_CALC_FOUND_ROWS * 
FROM tbl_name
WHERE id > 100 
LIMIT 10;

# пример "проскочившего" запроса
SELECT *
FROM tbl_name_2
WHERE id=12;

SELECT FOUND_ROWS();

И вот уже FOUND_ROWS() возвращает совершенно не то что нужно. Для создания тестовой загрузки проекта можно пользоваться Apache ab например вот так

# 900 раз запросить страницу с 10 конкурентными запросами
ab -c 10 -n 900 http://cocainum.info/post/301/

В моей ситуации во время такого тестирования мелкие запросы как раз влезали между запросами с лимитом и запросами подсчета рядов. В результате пейджинг думал что страниц у него ровно одна штука и исчезал со всех своих страниц как класс, пока шла нагрузка с конкурентными запросами.
А теперь внимание вопрос для третьего класса средней школлы.. Как поделить три яблока на четверых чтобы каждый получил по яблоку и никто не получил по лицу. Как же это решить? Я не нашел удобного толкового решения. Callback hell забарывает и на код становится жутко глядеть. Решение есть, смотрим тут Pooling connections. То есть если необходимо по каким-то причинам строго последовательно выполнять запросы, то из пула специально берем отдельный коннект и пользуемся им. Выглядеть это будет примерно так:

pool.getConnection(function(err, conn) {
  conn.query( 'SELECT SQL_CALC_FOUND_ROWS * FROM tab1 LIMIT 100,10', function(err, rows) {
    conn.query('SELECT FOUND_ROWS() as cnt', function(err, rows){
      // получаем общее кол-во строк
      // ...
      // освобождаем соединение
      conn.release();
    });
  });
});

В прокладке я это реализовал, но пока что выглядит все это жутко, надо либо свыкнуться с этой мыслью, либо придумать что-то лучше. Пока переделанную версию выкладывать смысла нет по-моему.
Стоит обратить внимание на секцию настроек "Pool options" хотя бы чтобы научиться регулировать количество соединений connectionLimit.
Вообще доделать конечно надо ради интереса, но по-хорошему надо переезжать уже на Sequelize или что-то такое.

О том что такое Grunt и зачем он нужен в общих чертах расскажет статья "Grunt для тех, кто считает штуки вроде него странными и сложными".

Бьюсь об заклад, вы наверняка уже что-то слышали про Grunt. Что ж, Grunt — это, по сути, планировщик задач. Grunt может делать все эти задачи за вас. Стоит лишь установить его, что, кстати, не так уж и сложно, и эти операции будут происходить автоматически, так, что вам про них даже не придётся вспоминать.

© frontender.info

Решил открыть тег ссылки, потому что перетягивать все на свете устанешь (да и вообще как-то не комильфо без необходимости по-моему), в закладках браузера потеряется а тут хоть как-то.. в общем это лирика.

Статья "Пишем качественный код на jQuery" освещает очевидно-понятно какие вопросы. К прочтению не то что обязательно, но может быть очень полезно.

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

© frontender.info