• XenServer vs Proxmox

    feedbee
    @feedbee Автор вопроса
    Алексей: не будет, потому что у обеих систем ядра со своими патчами.
  • XenServer vs Proxmox

    feedbee
    @feedbee Автор вопроса
    Алексей: пришли к тому, что используем обе системы в разных ситуациях :) Проблемы есть и там, и там. Оба решения требуют профессиональных знаний и/или много времени на решения внезапно возникающих проблем. Если нужно поднимать полноценные независимые виртуалки, лучше брать Xen. Если нужно просто разделить "пространства", например для нескольких сайтов, лучше Proxmox (профит тот же, но проще немного). Ну и во многом выбор все равно будет субъективным.
  • Взаимосвязи объектов-сущностей (entities) в ORM Doctrine2

    feedbee
    @feedbee Автор вопроса
    Ок. С аспектом flush-ей понятно. Но что делать с таким. Пользователь просит сменить e-mail и в качестве нового значения указывает такое, которое в базе уже есть — дубликат.

    // Model:
    class UserModel
    {
    function getUser($id){return $entityManager->find('User', $id);}
    function saveUser($user)
    {
    /*Здесь проверка на дубликаты e-mail-а и мое исключение;*/
    $entityManager->persist($user); // в случае TrackingPolicy = DEFERRED_EXPLICIT
    }
    }

    // Controller:
    $model = new UserModel;
    $user = $model->getUser(1);
    $user->setEmail('duplic@te');
    $model->saveUser($user); // вот здесь должно вылететь мое исключение о дубликате

    // Later in View:
    $model = new UserModel;
    $user = $model->getUser(1);
    echo $user->getEmail(); // напечатан неверный e-mail пользователя

    // Later:
    $entityManager->flush();


    Где бы не находился $entityManager->flush();, ситуация не изменится. Все равно после $user->setEmail() в поле User::$email уже новое значение, которое будет выведено во View. Единственный вариант, который я тут вижу (и наверное это и есть true way в случае ORM) — это проверять валидность адреса прямо в методе $user->setEmail() и не давать установить невалидное значение.

    Другой вариант, который мне ну совсем не нравится, это в UserModel::saveUser() в случае ошибок делать либо EntityManager::refresh, либо EntityManager::detach. Оба метода вызовут глобальные неприятные последствия.

    Короче, я понимаю, что мое мышление, перенесенное из модели SQL-запросов в случае ORM работает неверно. И я прихожу к пониманию того, что наверное ORM нужно прежде всего там, где объекты долго в памяти — десктопные приложения и серверы на событиях, где не нужно постоянно вытягивать граф объектов из базы. Там объекты расползутся по приложению и изменение в одном месте вызовет изменения во всех других местах, и это круто. Типа $user->setEmail($x); и с этого момента e-mail считается уже измененном.

    А в скрипте на обработку запроса все, что нужно — это только мэппинг result set-а в объекты. А дальнейшее отслеживание их состояний не нужно. Когда надо что-то сохранить, проще явно попросить это сделать. Я делаю $user = get(), потом $user->setX($newX), потом save($user) — и только после save я знаю, что все сохранено.
  • Взаимосвязи объектов-сущностей (entities) в ORM Doctrine2

    feedbee
    @feedbee Автор вопроса
    В таком случае проблема будет таком коде:
    $user1 = $entityManager->find('User', 1);

    // ...

    $user2 = $entityManager->find('User', 1);

    // ...

    catch (...)
    {
    $entityManager->detach($user1)
    }

    // ...

    $user2->setOther('Other');
    $entityManager->flush();


    Такая ситуация легко может возникнуть в случае рекурсии.
  • Взаимосвязи объектов-сущностей (entities) в ORM Doctrine2

    feedbee
    @feedbee Автор вопроса
    Основной вопрос не в этом. Я подкорректировал код в примере, чтобы убрать неверный акцент. Основной вопрос в том, что объект был получен, изменен, а во второй раз получен уже измененным, хотя это не предполагалось…
  • Мониторинг нескольких серверов (<10)

    feedbee
    @feedbee Автор вопроса
    Zenoss — штука интересная. Я так и не понял, решит ли она все мои задачи, потому что не смог пока все настроить как положено. Вообще, везде пишут, что эта система сложна в освоении.
  • Мониторинг нескольких серверов (<10)

    feedbee
    @feedbee Автор вопроса
    По правде говоря больше из интереса. Хотя на самом для контроля происходящего не помешает. Этот показатель в нормальной ситуации должен быть в определенных пределах, а внезапное его изменение может говорить о появлении проблем.
  • Мониторинг нескольких серверов (<10)

    feedbee
    @feedbee Автор вопроса
    Уточняю: требуется система, которая покажет историю загрузки ресурсов, т.е. значения и графики, а не просто On/Off/Warning.
  • XenServer vs Proxmox

    feedbee
    @feedbee Автор вопроса
    У меня завелась. Вероятно дело в какой-то частности…
  • Запуск процессов в фоне Linux

    feedbee
    @feedbee Автор вопроса
    У меня и так использовался nohup, в таком виде:
    $pid = shell_exec(«nohup $command > /dev/null 2>&1 & echo $!»);

    Изменение вида на ваш результатов не дало, но все равно спасибо.