http://symfony-gu.ru/blog/ru/symfony2-testing-hints/

Ниже приводится небольшое руководство по использованию. Вам понадобится PhpStorm 2.0 и Symfony 1.1 или более поздней версии (включая Symfony 2.0 BETA – в оригинальное руководство не входило, но мной проверено). Если у вас нет Symfony, руководство по установке вы можете найти здесь.

В первую очередь нам нужно настроить новый command line tool.

Загрузка Symfony Commands

Откройте меню Settings | Command Line Tool Support и нажмите в появившемся окне кнопку Add. Вам будет предложено три опции, выберите “Symfony”:

Затем укажите путь к файлу $Symfony_home$/data/bin/symfony. Для типичной конфигурации (из руководства симфони) путь будет следующим: $Project_root$/lib/vendor/symfony/data/bin/symfony. Описания команд Symfony будут загружены и сохранены в файл среди прочих настроек проекта. В диалоговом окне настроек это будет выглядеть следующим образом:

• Поле Tool Path содержит путь к CLI (php и фреймворка) и будет различаться в зависимости от фреймфорка. Для Symfony это “php  $path_to_symfony$”  и “$Zend_Framework_Tool_home$/bin/zf.bat” для Zend Framework. $PhpExecutable$ – это макрос, он заменяется на путь к исполнимому файлу CLI PHP, $ProjectFileDir$ это тоже макрос, он заменяется на полный путь к проекту. Макросы позволяют легко перемещать настройки между несколькими IDE.
• Полный Tool Path может быть очень длинным и неудобным в наборе, поэтому имеется алиас, который представляет из себя строку, которую можно использовать для вызова CLI вместо Tool Path.
• Чекбокс “Enable” поможет вам легко включать и отключать команды фреймворка из списка автоподстановки, не удаляя настройки. В данном случае чекбокс включен, таким образом команды Symfony будут отображаться в списке. Нажмите Ctrl +Shift+X или выберите в меню Tools | Run Command… и наберите алиас “s”:

Используем Symfony Command Line

Теперь создадим простой проект на Symfony c использованием Command Line Tool, как это описано в “Getting  Started” документе.

Создаем проект Symfony

Нажимаем Ctrl +Shift+X и набираем:

Команда имеет два параметра:

• Обязательный параметр “name”. Мы воспользуемся макросом $ProjectName$, который будет заменен на наименование проекта PhpStorm.
• Опциональный параметр “author”.

Перед выполнением команды макрос $ProjectName$ будет заменен на имя проекта и алиас “s” будет заменен на Tool Path. В данном случае это будет что-то типа “usr/bin/php /home/sfproject/lib/vendor/symfony/data/bin/symfony”.

Результат – будет создан проект:

Настройка доступа к базе данных

Теперь настроим доступ к БД при помощи команды “php symfony configure:database “mysql:host=localhost;dbname=dbname” root mYsEcret”

Создание приложения Frontend

Давайте создадим приложение frontend без экранирования вывода (что в общем-то сделает его менее защищенным!). Нажмите Ctrl +Shift+X и наберите:

Заметьте, что опции команд также поддерживаются. В примере выше это была опция –escaping-strategy=false.

Результат работы команды:

Права доступа к директориям

Следующим шагом является установка прав на директории cache/ и log/. Это также можно сделать при помощи Command Line Tool Support. Тул попытается выполнить команды (макросы таже доступны). Но имейте в виду, что команды “chmod” по-умолчанию нет в windows системах (если вы не используете например cygwin).

Результат:

Примечание:

Вообще говоря для установки прав можно нужно использовать команду “symfony project:permissions” // hudson@work

После этого надо настроить web-сервер, как описано в документации, и запустить его.

Тестирование

Проверьте доступ к новому приложению – откройте в браузере http://localhost:8080/index.php/ и затем проверьте доступ к dev окружению http://localhost:8080/frontend_dev.php/.

Если вы видите такую страницу, ваш проект успешно создан:

Добавляем пользовательский task.

Давайте создадим простой таск “hello”. Подразумевается что ранее вы уже настроили команды Symfony, как это описано выше и создали проект.

Нажмите Ctrl+Shift+X и выполните команду:

В директории lib/task будет создан класс “helloTask”.

Откройте класс helloTask в редакторе и выполните следующие несложные изменения в его методе “execute”:

Откройте description file для Symfony: выберите Settings |  Command Line Tool Support и нажмите кнопку “Open definition in editor”.

Добавьте описание новой команды “hello”:

Текст описания:

<command>
    <name>
        hello
    </name>
    <help>
        My first task with no parameters.
    </help>
</command>

Для проверки новой команды выполните:

Результат выполнения отобразится в консоли:

Решение проблем

Если у вас возникнут проблемы после редактирования файла описания и нужная вам команда не появится, откройте таб Validation в консоли. Этот таб показывает информацию о проблемах парсинга файла описания:

Вы также можете получить информацию о формате файла описания из схемы .idea/commandlinetools/schemas/frameworkDescriptionVersion1.1.xsd. Этот путь указан в созданном файле описания и редактор выполняет валидацию автоматически с его использованием.

Hope this hepls как говорится, ваш hudson@work

Вам по прежнему будет нужен уникальный ключ для каждого пользователя.

Ниже представлен небольшой workaround, позволяющий менять ключи для работы с различными проектами на assembla.com.

1) разместите где-либо в $PATH скриптик (назовем его gitssh):

#!/bin/sh
key=$(git config ssh.key)
 
if [ -z "$key" ]; then
  git_opts=""
else
  git_opts="-i ${key}"
fi
 
exec ssh $git_opts "$@"

2) установите переменную GIT_SSH чтобы она указывала на этот скрипт:

export GIT_SSH=gitssh

3) выполните настройку ключа для проекта1 в его директории

git config ssh.key ~/.ssh/my_cool_project1_key.pub

и для проекта2 в его директории

git config ssh.key ~/.ssh/my_cool_project2_key.pub

Вот и все работает ) Успехов!

http://www.assembla.com/spaces/breakoutdocs/wiki/Different_SSH_keys_for_different_projects

Схема:

Vendor\MyBundle\Entity\User:
  type: entity
  table: user
  id:
    id:
      type: bigint
      generator:
        strategy: AUTO
  fields:
    # ...
    updated:
      type: datetime
      nullable: true
    created:
      type: datetime
      nullable: true

Далее полагаем что сущности сгенерированы. При создании новой сущности вызывается констуктор, поэтому даты устанавливаем там:

<?php
// Vendor/MyBundle/Entity/User.php
class User{
    // ....    
    /**
     * @var datetime $created
     */
    private $created;
 
    /**
     * @var datetime $updated
     */
    private $updated;
 
    public function __construct()
    {
        $this->created = $this->updated = new \DateTime("now");
    }
    // ....    
}

Для того чтобы при обновлении сущности updated также обновлялся бы, нам надо воспользоваться lifecycle callback. Модифицируем схему и генерим по ней модель:

Vendor\MyBundle\Entity\User:
  type: entity
  table: user
  # ...
  lifecycleCallbacks:
    preUpdate: [ preUpdate ]

После генерации у вас в классе сущности появится метод preUpdate, который надо слегка модифицировать:

<?php
// Vendor/MyBundle/Entity/User.php
class User{
    // ....    
    /**
     * @orm:preUpdate
     */
    public function preUpdate()
    {
        $this->updated = new \DateTime("now");
    }
    // ....    
}

Берем и пользуемся )

Источник: http://www.doctrine-project.org/blog/doctrine2-behaviours-nutshell. Посмотрите, там еще много интересного.

UPDATE 20 января 2012: статья обновлена в соответствии с современными реалиями SF 2.0.9 (фактически изменения коснулись именования тага и события)

Итак, начнем с определения службы:

YAML:

# Vendor\MyBundle\Resources\config.yml
services:
    # ...
    preexecute.listener:
        class: Vendor\MyBundle\Listener\PreExecuteListener
        tags:
            - { name: kernel.event_listener, event: kernel.controller, method: onKernelController }

XML:

# Vendor\MyBundle\Resources\config.xml
        <service id="kernel.listener.pre_execute" class="Vendor\MyBundle\Listener\PreExecuteListener">
            <tag name="kernel.event_listener" event="kernel.controller" method="onKernelController" priority="0"/>
        </service>

Создадим также определение нашей службы в положенном ей месте:

// Vendor\MyBundle\Listener\PreExecuteListener.php
 
namespace Vendor\MyBundle\Listener;
 
use Symfony\Component\EventDispatcher\Event;
use Symfony\Component\HttpKernel\HttpKernelInterface;
use Symfony\Component\HttpKernel\Event\FilterControllerEvent;
 
class PreExecuteListener
{
  public function onKernelController(FilterControllerEvent $event)
  {
    if (HttpKernelInterface::MASTER_REQUEST === $event->getRequestType()){
      $controllers = $event->getController();
      // контроллер должен существовать
      if (isset($controllers[0])){
        $controller = $controllers[0];
        // метод должен существовать
        if(method_exists($controller, 'preExecute')){
          $controller->preExecute();
        }
      }
    }
  }
}

Вот и все! ) Теперь в нужном контроллере объявляем метод preExecute() и наслаждаемся нашими танцами с бубном )

Вот наглядный пример: bad behavior блокирует доступ к sitemap.xml (генерируемый при помощи XML-Sitemp plugin):

В общем, как поется в песне – “думайте сами, решайте сами – иметь или не иметь”… гемор с трафиком. Или со спамом.

Мои entities определены по привычке в YAML формате, поэтому я буду описывать именно его. Итак, укажем нашей сущности использовать кастомный Repository:

# src/Vendor/MyBundle/Resources/config/doctrine/metadata/orm/Vendor.MyBundle.Entity.User.dcm.yml
Vendor\MyBundle\Entity\User:
    type: entity
    table: user
    ...
    repositoryClass: Vendor\MyBundle\Repository\UserRepository
    ...

После этого можно создать класс UserRepository.php в директории src/Vendor/MyBundle/Repository или же выполнить команду doctrine:generate:repositories:

>php app\console doctrine:generate:repositories VendorMyBundle
Generating entity repositories for "VendorMyBundle"
  > OK generating Vendor\MyBundle\Repository\UserRepository
  > SKIP no custom repository for Vendor\MyBundle\Entity\UserData

У нас есть класс репозитория. Добавим в него метод выбора случайного юзера:

  public function getRandomUser()
  {
    // mapper для результата
    $rsm = new ResultSetMapping;
    $rsm->addEntityResult('Vendor\MyBundle\Entity\User', 'u');
    $rsm->addFieldResult('u', 'id', 'id');
    // тут я использую NativeQuery - перевести этот запрос в DQL для меня сейчас слабо )
    // также примем допущение что user не содержит "дыр" в ID
    $query = $this->getEntityManager()->createNativeQuery(
      'SELECT id FROM user JOIN ( SELECT CEIL(RAND() * (SELECT MAX(id) FROM user)) AS id ) AS r2 USING (id)',
      $rsm
    );
    // ищем случайный ID
    $user = $query->getSingleResult();
    // на выходе получаем полноценный Vendor\MyBundle\Entity\User (хотя как вариант можно написать маппер на все необходимые поля)
    return $this->find($user->getId());
  }

В контроллере пользуемся репозиторием так:

  public function someAction()
  {
    $em = $this->get('doctrine.orm.entity_manager');
    $userRepo = $em->getRepository('VendorMyBundle:User');
    $randomUser = $userRepo->getRandomUser();
  }

P.S. данный код возможно далек от идеала, тем не менее на пробную работу с репозиторием и native sql мной было потрачено некоторое время, результатами своих изысканий я с вами и делюсь )

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

Положим у нас в нашем пакете есть служба Company\SuperBundle\Service\CoolService описываемая следующей конфигурацией:

# app/config/config.yml
services:
    giveMeCool:
        class: Company\SuperBundle\Service\CoolService
        arguments: [%arg1%, %arg2%]

Все идет хорошо, пока нам не требуется другая служба. Например мне понадобился logger. Вообще говоря это есть в документации, но пришлось повозиться пока я это нашел: другую службу можно указать в аргументах своего сервиса через @svcname:

# app/config/config.yml
services:
    giveMeCool:
        class: Company\SuperBundle\Service\CoolService
        arguments: [%arg1%, %arg2%, @logger]

Соответственно код конструктора службы надо немного модифицировать:

# src/Company/SuperBundle/Service/CoolService.php
  //...
  // services
  protected $logger = null;
 
  public function __construct( $arg1, $arg2, \Symfony\Bundle\ZendBundle\Logger\Logger $logger)
  {
    $this->logger = $logger;
    //...

Тип сервиса можно указать явно (как в примере), тогда мы сможем как минимум пользоваться подсказками нашей IDE (что в Symfony2 получается не часто).

Update

Читатель Костег в комментариях предложил более общее решение для данного кейса: можно передавать в пользовательскую службу не отдельные службы, а весь service container разом (мало ли когда и какая из служб вам потребуется):

# app/config/config.yml
services:
    giveMeCool:
        class: Company\SuperBundle\Service\CoolService
        arguments: [%arg1%, %arg2%, @service_container]

Теперь в классе вашей службы вы сможете получить доступ к любой из служб, определенных в рамках вашего приложения: templating, logger, request, routing etc…

# src/Company/SuperBundle/Service/CoolService.php
  //...
  // services
  protected $serviceContainer = null;
 
  public function __construct( $arg1, $arg2, \Symfony\Component\DependencyInjection\Container $container)
  {
    $this->serviceContainer = $container;
    $this->serviceContainer->get('routing');
    //...

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

Перевод статьи про анализ сложных MySQL запросов:

Для данной статьи возьмем запрос из статьи про ORDER BY RAND, так он достаточно интересен для рассмотрения различных аспектов запросов. Он содержит:

• Подзапросы;
• Объединения;
• Особые случаи;
• JOIN’ы
• Сортировку ORDER BY + LIMIT

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

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

Рассмотрим результаты EXPLAIN запроса:

> EXPLAIN EXTENDED
(SELECT r1.name FROM random AS r1
   JOIN (SELECT (RAND() *
                (SELECT MAX(id) FROM random)) AS id
        ) AS r2
  WHERE r1.id >= r2.id
  ORDER BY r1.id ASC
  LIMIT 1)
UNION ALL
(SELECT r1.name FROM random AS r1
   JOIN (SELECT (RAND() *
                (SELECT MAX(id) FROM random)) AS id
        ) AS r2
  WHERE r1.id >= r2.id
  ORDER BY r1.id ASC
  LIMIT 1);

И собственно сами результаты:

+----+--------------+------------+--------+---------------+---------+---------+------+---------+----------+------------------------------+
| id | select_type  | table      | type   | possible_keys | key     | key_len | ref  | rows    | filtered | Extra                        |
+----+--------------+------------+--------+---------------+---------+---------+------+---------+----------+------------------------------+
|  1 | PRIMARY      | <derived2> | system | NULL          | NULL    | NULL    | NULL |       1 |   100.00 | Using filesort               |
|  1 | PRIMARY      | r1         | ALL    | PRIMARY       | NULL    | NULL    | NULL | 1000000 |   100.00 | Using where                  |
|  2 | DERIVED      | NULL       | NULL   | NULL          | NULL    | NULL    | NULL |    NULL |     NULL | No tables used               |
|  3 | SUBQUERY     | NULL       | NULL   | NULL          | NULL    | NULL    | NULL |    NULL |     NULL | Select tables optimized away |
|  4 | UNION        | <derived5> | system | NULL          | NULL    | NULL    | NULL |       1 |   100.00 |                              |
|  4 | UNION        | r1         | range  | PRIMARY       | PRIMARY | 4       | NULL |  153726 |   100.00 | Using where                  |
|  5 | DERIVED      | NULL       | NULL   | NULL          | NULL    | NULL    | NULL |    NULL |     NULL | No tables used               |
|  6 | SUBQUERY     | NULL       | NULL   | NULL          | NULL    | NULL    | NULL |    NULL |     NULL | Select tables optimized away |
| NULL | UNION RESULT | <union1,4> | ALL  | NULL          | NULL    | NULL    | NULL |    NULL |     NULL |                              |
+----+--------------+------------+--------+---------------+---------+---------+------+---------+----------+------------------------------+

Запрос состоит из 2х SELECT’ов и UNION’а. Результат UNION получается за счет объединения id 1 и 4 (union1,4), что можно увидеть в последней строке.

Id 1 это JOIN между временной таблицей derived2 и random. Поскольку id остается неизменным, запрос как правило является частью JOIN. deriverd2 это результат id 2 (DERIVED) с его подзапросом id3.

Мы использовали несколько трюков для того чтобы довести до оптимайзера идею, что ему не надо читать данные с диска при выполнении различных частей запроса:

• MAX(id) может быть оптимизирован в данном случае последним значением индекса. Это единичный поиск, который не требует ни сортировки, ни группировки… (id 3 and 6)
• Мы вынесли рассчет RAND() * MAX(id) в подзапрос, чтобы быть уверенными, что оптимизация MAX() действительно имеет место (вычисляется один раз // прим. пер.) (id 2 and 5)
• Мы использовали ORDER BY + LIMIT чтобы оптимайзер выполнил INDEX READ и остановился после обнаружения одной строки. (id 1 and 4)

стоимость выборки

Мы можем доказать нашу теорию при помощи проверки SHOW STATUS.

> FLUSH STATUS;
> SELECT ...;
> SHOW SESSION STATUS;

Команда FLUSH STATUS сбрасывает значения счетчиков для текущей сессии, команда SHOW SESSION STATUS отображает счетчики:

| Select_full_join                  | 0         |
| Select_full_range_join            | 0         |
| Select_range                      | 2         |
| Select_range_check                | 0         |
| Select_scan                       | 1         |

Мы имеем 2 range scans (ORDER BY + LIMIT), по одному для каждой части нашего UNION и 1 table scan для чтения результатов UNION и отправки их на клиент.

Для того чтобы доказать что мы не используем дорогую сортировку – проверим счетчики Sort-*:

| Sort_merge_passes                 | 0         |
| Sort_range                        | 0         |
| Sort_rows                         | 0         |
| Sort_scan                         | 0         |

Таблица для тестов содержит 1 миллион строк, но мы читаем всего несколько штук из них:

## наши временные таблицы:
| Created_tmp_tables                | 3         | 2 вторичные таблицы + UNION RESULT
## тут мы пишем только во временные таблицы в памяти
| Handler_write                     | 4         | (1 строка + 1 строка) для вторичных таблиц + 2 строки для результата UNION
## MAX(id) выполняет Index-lookup для _last_ id
| Handler_read_first                | 2         |
## ... и мы ищем одну строку для random-id внутри JOIN
| Handler_read_key                  | 2         |
| Handler_read_next                 | 0         |
| Handler_read_prev                 | 0         |
| Handler_read_rnd                  | 0         |
## все чтения из временных таблиц не индексированы
| Handler_read_rnd_next             | 5         |
## виртуальная стоимость запроса ... "foobars"
| Last_query_cost                   | 10.499000 |

а что насчет “старого доброго” ORDER BY RAND?

Ради прикола посмотрим на классический запрос еще раз:

> FLUSH STATUS;
> SELECT name FROM random ORDER BY RAND() LIMIT 1;
> SHOW SESSION STATUS;
> EXPLAIN SELECT name FROM random ORDER BY RAND() LIMIT 1;
+----+-------------+--------+------+---------------+------+---------+------+---------+---------------------------------+
| id | select_type | table  | type | possible_keys | key  | key_len | ref  | rows    | Extra                           |
+----+-------------+--------+------+---------------+------+---------+------+---------+---------------------------------+
|  1 | SIMPLE      | random | ALL  | NULL          | NULL | NULL    | NULL | 1000000 | Using temporary; Using filesort |
+----+-------------+--------+------+---------------+------+---------+------+---------+---------------------------------+

В общем дело было так: ALL rows – все строки – сортируются во временной таблице и озвращается лишь одна!

## цена запроса "несколько" выше :)
| Last_query_cost                   | 210744.186500 |
## у нас используется только одна временная таблица, с намного бОльшим числом строк
| Created_tmp_tables                | 1             |
| Handler_write                     | 1349207       |
## Выполняется один ГИГАНТСКИЙ table-scan для заполнения временной таблицы
| Select_scan                       | 1             |
| Handler_read_rnd_next             | 2349209       |
## и тяжелейшая сортировка
| Sort_merge_passes                 | 19            |
| Sort_range                        | 0             |
| Sort_rows                         | 2             |
| Sort_scan                         | 1             |

Источник: http://jan.kneschke.de/projects/mysql/analyzing-complex-queries/

Перевод как водится мой. Также хочу отметить что не смотря на небольшой объем текста перевод выдался тяжелым с точки зрения понимания. Если видите что я где-то накосячил или не прав – отпишите в комметариях или в личку. 10nx )

Да, лично для меня статья оказалось полезна в плане использования счетчиков и интерпретации их значений. Надеюсь и вам тоже.

Помимо собственно FTP на сервер, человечку нужен был виртуальный хост для его отладочных нужд. Сервер как правило использовался только проверенными людьми, поэтому особо с безопасностью никто особо не заморачивался. Ан вот приспичило. На счастье, попался мне на просторах интерентов документик ProFTPD mini howto, в котором подробно разбирается почему демон не хочет работать с прямыми симлинками из хомяка в docroot виртуальника (в моем случае). Собственно остановился я на этом решении:

Filesystem Tricks [...]

To have an exact duplicate of the /var/ftp/incoming directory available in /home/bob/incoming and /home/dave/incoming, use one of these commands:

Linux (as of the 2.4.0 kernel):

  mount --bind /var/ftp/incoming /home/bob/incoming
  mount --bind /var/ftp/incoming /home/dave/incoming

Что я в общем-то и применил.

P.S. Надеюсь дыр в безопасности не добавил )