Fi1osof

Я не правильный программист, всегда это говорил, так что и посудиться могу :) На самом деле, когда я на почту получил от них письмо (обычное, не бумажное), я ответил радостно «Вау! Спасибо за ивенты! :)» ну и в том роде. Тут сразу было понятно, что им ловить вообще нечего, это для них только боком выйдет.

Но в плане встречного иска мне без тебя и Андрея нечего им предъявлять. Конкретно моих интересов они никаких не задели, ведь они не используют мои не популярные модули :)

На хабре предлагают их дальше судить. Василий, есть желание предъявить иск к Фабрике?

Прикольно было бы)))

Думаю, она еще поубавится :)

Думаю, они просто хотели меня покошмарить, думали я испугаюсь иска на 500 000, удалю топик, извинюсь и т.п. Не проканало…
На счет 240 000 — позже напишу подробный топик, обсудим. Они предоставили Предварительный Договор с брифом и там расписали цифры, вообще никак не увязывающиеся с ценами на сайте. Я собственно даже в возражениях указывал на вероятный сговор Фабрики с этой сторонней компанией-клиентом (и Суд принял этот довод, вызвав третье лицо на заседание, но те не явились, прислав формальную отписку), ибо и цифры явно из пальца высосаны, и Предварительный Договор в IT даже среднего уровня — это какой-то нонсенс.

Собственно, это наверно основная причина почему они подали иск на меня. Есть инсайд, что они долго думали подавать или не подавать в суд. Но в итоге все-таки подали, но подали уже в начале октября, хотя статья была написана в июле. Почему? 98% как раз из-за высоких позиций сайта по этому запросу.

Спасибо :)
Запрос «Фабрика сайтов отзывы» — второй по популярности на моем сайте. Думаю это влияет на то, сколько потенциальных клиентов предупреждено на счет работы с этой «компанией».

Хорошо, в данном случае на xPDO больше строк придется написать.

Но к себе Вы не столько критичны. :)

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

В очередной раз поддерживаю предложение не плевать друг на друга, а направить свои усилия на развитие MODX. От этого больше пользы.

А вы меньше смотрите на мою бестактность и больше читайте суть техническую. Я программист, а не политик. Особо слова не выбираю. Но попробуйте сказать что техническое возражение мое на комментарий было не корректным. Где я там допустил ошибку и в чем? Меньше обращайте внимание на мой тон и больше на техническую составляющую, и вот вам больше пользы.

$pdo = $modx->getService('pdoFetch');
$pdo->setConfig(array(
	'select' => 'id,uri,pagetitle,content',
	'limit' => 2000
));
$pdo->makeQuery();
$pdo->addSelects();
$query = $pdo->prepareQuery();
$query->execute();
while($row = $query->fetch(PDO::FETCH_ASSOC)) {
	print $row['pagetitle'];
}

Василий, вот зачем так много строк? Все то же самое на xPDO:

$q = $modx->newQuery('modResource');
$q->select(array("id","uri","pagetitle","content"));
$q->limit(2000);
$query = $q->prepare();
$query->execute();
while($row = $query->fetch(PDO::FETCH_ASSOC)) {
	print $row['pagetitle'] . "\n";
}

Да, твой запрос сейчас максимально близок к чистому xPDO, но при этом все равно строк больше — раз, а во-вторых, зачем в таком случае изучать просто альтернативные методы вместо нативных?
Это что касается скорости и синтаксиса.

Эээ, чтобы вы понимали, топикстартер — не я :)
А коммент мой был ответом на другой коммент, не совсем корректный в техническом плане.

По поводу компетенций: сама модель MODX-а изначально ориентирована на не разработчиков. Это не секрет. И я уверен, что большинство MODX-разработчиков, как и в первом комментарии, не совсем отличит PDO от xPDO и т.п. Поэтому я и говорю про компетенции. Поэтому я и говорю что из-за этого легче пиарить синтаксический сахар.

На счет кол-ва использований вообще не спорю. Его много кто использует в том числе и за рубежом. Пруфф. Но топик касался сравнения скорости и ваши комментарии немного некорректными были, поэтому я и расставил точки над i. Если бы топик был о том кому что больше нравится, я бы не сунулся сюда.

P.S. Второй способ у вас — PDO, а не xPDO.

Как-то не совсем я корректно ответил. Во втором случае от xPDO только формирование запроса, не хватает getCollection.

Вообще-то самый что ни на есть xPDO.

$q = $modx->newQuery('modResource');

— создается объект запроса xPDOQuery, который, как понятно из названия, имеет непосредственное отношение к xPDO.

$s = $q->prepare();

Возвращает PDO-объект PDOStatement. Открою вам тайну: pdoTools, использующие в своей работе xPDO, так же в итоге приходят к этому объекту для выполнения запросов к БД, без этого просто никак.

$s->execute();

Выполнение непосредственно запроса к БД. Так что здесь не только формирование запроса, но и выполнение его и обработка полученных данных.

А getCollection() — это не только все выше перечисленное, но еще и набивка данных в конечные xPDO-объекты. А это уже совсем другая задача. Ну и следует отметить, что в первом случае getCollection() тоже не выполняется, а просто так же выполняется запрос к БД и возвращаются полученные данные. getCollection() выполняется у pdoFetch в совсем другом методе.

Ну и fetch(PDO::FETCH_ASSOC) лучше было бы заменить на fetchAll, а потом пройтись по массиву, как в первом случае. Так условия для сравнения были бы ровнее (:

Да, в этом тоже отличие этих двух примеров. В первом случае идет выборка сразу всех записей и возвращается конечный массив данных, а во втором случае идет построчный перебор полученного результата. Но, во-первых, это влияет на количество потребляемой памяти (что мы и видим наглядно), но на время выполнения почти не влияет. Что в одном случае, что в другом идет перебор 2000 результирующих записей. А во-вторых, здесь не должно быть цели приравнять результаты обоих вариантов к общему знаменателю. Здесь есть желание увидеть есть ли разница или нет. А разница безусловно будет. Объясню просто. Вот цепочка выполнения первого примера:
pdoTools -> xPDO -> PDO.
А вот цепочка второго примера:
xPDO -> PDO.
Найдите 10 отличий. Как ни крути, pdoTools не может быстрее работать, чем чистый xPDO, без которого сам pdoTools работать не может. Он может кому-то быть удобней в использовании, но не быстрее, потому что к выполнению первого варианта еще плюсуйте кучу методов отсюда, а второй вариант — конечный.

Именно по причине того, что многие не понимают до конца принципов работы xPDO, они и используют активно pdoTools искренне считая, что это самый быстрый и удобный способ взаимодействия с БД. Ну что? Василию надо отдать должное, он смог пропиарить свои наработки на базе массовой некомпетентности MODX-разработчиков. Ну, это уже каждому свое, и свое не каждому. Раз оно популярно, значит помогает в разработках. Но факт останется фактом — pdoTools никогда не будет работать быстрее и более гибко, чем чистый xPDO. Это можно даже тесты не проводить.

Просто ограничения до кроссдоменные запросы. Четкого решения не скажу, ковырять надо конкретную ситуацию.

Без разницы.

Пожалуйста!

Для нескольких контекстов особенно не требуется ничего лишнего делать. Сам прейикс не особо страшен в плане производительности. Важен именно тип кеш-провайдера. То есть если у вас, к примеру, memCached, то не страшно, что у разных контекстов разные кеш-префиксы, если в config.inc.php указан именно кеш-провайдер memCached. Будет мелкая потеря на повторном чтении памяти (если префикс у конкретного контекста отличается), но потеря там мизерная. А вот если у вас мемкеш, но по умолчанию используется файловый менеджер, то тут уже при старте MODX использует файловый менеджер, после чего уже поймет что надо использовать мемкеш и тогда только его задействует. Особенно это будет ощущаться при сбросе кеша, когда MODX начала будет кешировать все новые настройки в файлы, читать их и только потом перейдет на память.

Ничего несколько не указывается. Логика такая: данная настройка в config.inc.php должна соответствовать используемому префиксу в MODX-е. Возьмите в консоли выполните print $modx->getOption('cache_prefix'); или просто в шаблоне вставьте [[++cache_prefix]], чтобы увидеть какой сейчас префикс используется. И вот это значение и должно быть указано в config.inc.php

А никак. Тут замкнутый круг: не была еще получена переменная префикса, чтобы получить настройки контекста, чтобы получить из него настройку префикса. Так что в любом случае придется указывать и там и там.

Василий, удали мой профиль со всеми моими топиками и комментами отсюда. Игра в одни ворота — это не правильно. Свой коммент оставил, мой удалил, хотя я там ни слова грубого не сказал. Так не делается.