Как повторить эту проблему. Допустим имеем класс RevisionsSets с таким вот определением реляций:

        /**
	 * @return array relational rules.
	 */
	public function relations()
	{
		return array(
			'pricesCount'=>array(
					self::STAT, 'Revisions', 'revisionSetId',
				),
		);
	}

Ну и в самом классе Revisions имеем следующую группу условий по-умолчанию:

        public function defaultScope() {
		$rev = Config::model()->getConfigValue("Shop", "CurrentRevision")->value;
		$t = $this->getTableAlias(false, false);
 
		return array(
					'condition' => "$t.revisionSetId=:rev",
					'params' => array('rev'=>$rev),
				);
 
	}

Что же происходит при вызове $revisionsSetModel->pricesCount?
STAT-реляция забирает количество записей, но при этом применяет defaultScope от модели Revisions и в итоге для всех экземпляров RevisionsSets считается некорректное количество записей.
Исправить такое поведение можно было бы допливанием CStatRelation и реализацией там поддержки условий, как это например сделано в HAS_MANY, MANY_MANY, BELONGS_TO.

Но мне в голову пришел более быстрый вариант. Я создал класс RevisionsResetScope, который наследует Revisions и переопределяет defaultScope:

<?php
 
class RevisionsResetScope extends Revisions {
	public function defaultScope() {
		return $this->resetScope();
	}
}

Этот класс и используем в реляции:

        /**
	 * @return array relational rules.
	 */
	public function relations()
	{
		return array(
			'pricesCount'=>array(
					self::STAT, 'RevisionsResetScope', 'revisionSetId',
				),
		);
	}

Вот такой костыль. Кстати, на форуме Qiang Xue решил отказаться от статистических запросов и CStatRelation в Yii Framework 2. Будем надеяться, что разработчики предусмотрят достойную замену.

Чтобы сделать Consumer(worker), который будет обрабатывать бесконечную очередь надо задать $consumer->consume(-1);. Тогда в цикле Thumper, где проверяется нужно ли нам выходить всё будет хорошо и наш обработчик будет работать вечно.

Но появился ещё один интересный вопрос - что делать, если внутри функции обработки сообщения произошел Exception? Я решил, что тогда мы отказываемся от этого сообщение и оно идет к другому обработчику. Реализовывать это лучше расширением класса Consumer:

class MyConsumer extends Consumer {
	public function processMessage($msg) {
		try {
			parent::processMessage($msg);
		} catch (Exception $e) {
			echo "Message rejected due to exception.\n".$e->getMessage()."\n";
			$msg->delivery_info['channel']->basic_reject($msg->delivery_info['delivery_tag'],true);
			//throw $e;
		}
	}
}

Соответственно ваш Consumer должен быть объектом класса MyConsumer.
Если же всё таки нужно кинуть этот Exception выше - убираем комментарий со строки throw $e;

Вот встречайте:

Блог Скобеева Константина

Twitter: @skobeeff

Два дня назад сервер с этим сайтом вывалился в даун. Я ждал, ну мало ли само починится. Так нет, даже сам сайт хостера лежал.
Сегодня нашел админа в фейсбуке, зарегистрировался на этом сайте и написал ему, мол в чем дело. Кстати админ - еврей и фамилия у него Yablon
На что он мне ответил:

oh k i was had problem toi pay them for the servers... my credit card limited to 2k ILS and the bill was much more this why it was down

Забавно получается. Я значит оплатил всё вовремя, а он тянул до последнего! Нехорошо!
Ну да ладно. Сервер заработал и на том спасибо.
Сейчас я этим постом тоже ставлю эксперимент.
Дело в том, что я решил на основе стандартных алгоритмов, доступных в сети алгоритмах посчитать ссылочную массу, которую передаст ссылка с этого поста.
Посмотрим, что из этого выйдет

Проект мой компилируется через ant. Поэтому самым простым  решением для этой задачи является модификация build.xml.

Открываем build.xml и прямо перед закрывающим тегом </project> пишем:


<target name="package-for-store" depends="jar">
<property name="store.jar.name" value="YourProjectNameHere"/>

<!-- don't edit below this line -->

<property name="store.dir" value="store"/>
<property name="store.jar" value="${store.dir}/${store.jar.name}.jar"/>

<echo message="Packaging ${application.title} into a single JAR at ${store.jar}"/>

<delete dir="${store.dir}"/>
<mkdir dir="${store.dir}"/>

<jar destfile="${store.dir}/temp_final.jar" filesetmanifest="skip">
<zipgroupfileset dir="dist" includes="*.jar"/>
<zipgroupfileset dir="dist/lib" includes="*.jar"/>

<manifest>
<attribute name="Main-Class" value="${main.class}"/>
</manifest>
</jar>

<zip destfile="${store.jar}">
<zipfileset src="${store.dir}/temp_final.jar"
excludes="META-INF/*.SF, META-INF/*.DSA, META-INF/*.RSA"/>
</zip>

<delete file="${store.dir}/temp_final.jar"/>

</target>


В итоге при компиляции ant package-for-store у нас появится пакет YourProjectName.jar в папке store со всеми сторонними библиотеками. Такой способ напомнил мне статичную линковку в C++..

Всё, теперь мой JAVA проект спокойно запускается в Hadoop кластере. А теперь можно заняться и созданием сайтов

# ip l sh eth0
17: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:c0:9f:55:6e:e5 brd ff:ff:ff:ff:ff:ff

38 connect(22, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::ffff:72.5.124.95", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28
6938 connect(22, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::ffff:72.5.124.95", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
Или вот так: Could not bind/listen. Network is unreachable.


Лечится это просто.

Редактируем файл /etc/sysctl.d/bindipv6only.conf и ставим там 0 вместо 1. Перегружаемся и всё работает! Проверено, у меня так hadoop, hbase не хотели запускаться.

Если хотите без перезагрузки, то можете ещё выполнить:


echo 0 > /proc/sys/net/ipv6/bindv6only
sysctl net.ipv6.bindv6only=0


По умолчанию пользователь видит регион, в котором он находится, что определяется по IP провайдера. За выдачу по региону отвечает одноименная настройка. Изменив её можно сразу же заметить разницу в выдаче по геозависимым запросам(например пицца, университет, такси). В адресной строке браузера можно заметить параметр lr=13, где 13 - это код региона в поисковике. Он то как раз и определяет нашу выдачу.

Так вот, к чему я это всё. Сегодня мне потребовался список регионов. Нашёл у Жилинского, но структура того списка мне не понравилась. Нашёл ещё один список на форуме Searchengines.ru. Тот тоже как то не так. Ну и решил я напарсить коды регионов с Яндекса. В итоге получилась таблица типа adjancy list(сопоставление предков и потомков через id -> parent).

Короче говоря, вот вам возможность скачать список регионов яндекса в виде MySQL дампа. Как это применять - уже ваш вопрос. За актуальность и достоверность не ручаюсь, но на первый взгляд вроде всё нормально.

BONUS: А вот как выглядит редактирование регионов в моей незарелизенной ещё пока что CMS-ке:

Скриншот админки регионов по яндексу

Идея позаимствована с Crunchbang linux wiki.

Создаём папку ~/bin и там файлик resize.sh следующего содержимого:

#! /bin/sh
for file; do
 if [ ! -e $file ]; then
 continue
 fi
 toname="./"$( echo $file | cut -f1 -d.)"_"$1".png"
 convert -channel A -geometry $1x$1 -quality 100 $file $toname
done

Делаем его выполняемым (chmod +x ~/bin/resize.sh), добавляем в ~/.bashrc export PATH=$PATH;~/bin чтобы мы могли вызывать это откуда нам вздумается и в терминале выполняем source ~/.bashrc чтобы наши изменения вступили в силу.

Теперь берём наш любимый файл-менеджер, например Thunar(стандартный в XFCE). Жмём правой кнопкой по картинкам, которые надо отресайзить, допустим до 32 пикселей, и "выбираем открыть  с помощью".
Там нам надо выбрать пункт "комманда" и вписать туда: "resize.sh 32 %N". не забудте снять галочку "Использовать эту программу для запуска файлов такого типа", а то Thunar будет запускать ресайз PNG картинок, вместо например просмоторщика картинок xfce.

Всё, теперь у нас появится файл вида старый_файл_32.png. Причем эта команда действует даже для несколько выбранных одновременно картинок. И никакой потери прозрачности PNG!

Для JPG надо в скрипте менять расширение и убирать -channel A, который отвечает собственно за transparency(прозрачность). Для GIF картинок его скорее всего надо будет оставить.

Вот так. Пользуйтесь на здоровье.

Логично, что простым переносом файлов тут не отделаешься, надо что-то где-то прописать.

По-умолчанию данные MySQL лежат в /var/lib/mysql. Мне захотелось, чтобы они были в /home/mysql. Переносим папку mysql куда нам нужно, затем лезем в конфиг MySQL (/etc/mysql/my.cnf).

Там есть опция:

datadir         = /var/lib/mysql

Вот её мы заменяем на следующее:

datadir         = /home/mysql

Пробуем перезапустить наш MySQL сервер (/etc/init.d/mysql restart) и в итоге у нас ничего не запускается.

Смотрим tail /var/log/messages и видим приблизительно такое:

 kernel: [ 2714.258037] audit(1227462526.718:13): type=1503 operation="inode_create" requested_mask="w::" denied_mask="w::" name="/home/mysql/yii.test" pid=19659 profile="/usr/sbin/mysqld" namespace="default"
 kernel: [ 2714.310572] audit(1227462526.770:14): type=1503 operation="inode_permission" requested_mask="rw::" denied_mask="rw::" name="/home/mysql/ibdata1" pid=19659 profile="/usr/sbin/mysqld" namespace="default"

Это нам говорит о том, что политика AppArmor запрещает всякие манипуляции мусклу в новой папке. И это естественно, ведь AppArmor думает, что базы лежат всё там же, в /var/lib/mysql.

Значит надо переписать конфиг AppArmor. Открываем и редактируем /etc/apparmor.d/usr.sbin.mysqld . В нём меняем всё, где упоминается /var/lib/mysql на /home/mysql. Затем перезапускаем AppArmor и MySQL:

sudo service apparmor restart
sudo /etc/init.d/mysql restart

И у нас всё работает! Такая же схема для Ubuntu.