Drupal + PostgreSQL (опять, да)

lexa - 14/Май/2009 10:51
Передайте разработчикам <программы такой-то>, что лучше бы они ее больше не разрабатывали

Похоже, что тестировать варез становится просто немодно, чем дальше, тем больше огорчаюсь.

Про моральных индусов я уже плакался, но там речь шла о 3rd-party модуле, а сейчас удивляюсь прямо таки на Drupal core. Удивляюсь, соответственно, сильнее, ибо для core поддержка PostgreSQL заявлено, а вот с тестированием... впрочем я повторяюсь.

Так вот, в comment.module имеется такой вот запрос:

(SELECT thread FROM comments WHERE nid = %d AND status = 0 ORDER BY timestamp DESC LIMIT %d) ORDER BY thread DESC LIMIT 1

На что Postgres вполне резонно сообщает Query failed: ERROR: multiple ORDER BY clauses not allowed и я с ним согласен. Понятно, что переписать нужно так:

SELECT thread FROM (SELECT thread FROM comments WHERE nid = %d AND status = 0 ORDER BY timestamp DESC LIMIT %d) AS thread ORDER BY thread DESC LIMIT 1

Таких мест я пока нашел два, вот патч, который правит оба: drupal-comment-module-order-by.diff.gz

Под MySQL не тестировал, мне не надо (и у меня нету). Потом, если Drupal team не тестирует под PgSQL, то должен же кто-то не тестировать под MySQL.

Патч, естественно, в drupal.org заслан. И, как обычно, если вы не знаете, что такое патч, то вам это не нужно.

Update:

  • Во-первых, этот баг виcит аж с девятого марта (его мало кто видит т.к. это кастомная сортировка комментариев, которую редко кто включает), причем как critical.
  • Во-вторых, как выяснили моральные индусы за 2 месяца(!) This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery' (в том смысле, что мой патч впрямую не подойдет).

Пойду нагажу им там в комменты.....

Comments

Anonymous (not verified) - 14/Май/2009 11:11

какой-то извращенный select, чего они хотят получить?

lexa - 14/Май/2009 11:41

Ну как что, отбираем N тредов по свежести, из них выбираем верхний по thread_id

maxcom (not verified) - 14/Май/2009 11:13

PS: чего-то с авторизацией в lj не так

Koshak (not verified) - 14/Май/2009 11:37

Вот пример с двумя ордерами:

sitepumper.ru=# explain analyze select ord_email from (select * from sc_order.orders order by ord_dat limit 10) as tt order by tt.ord_id;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=1.18..1.21 rows=10 width=520) (actual time=0.242..0.263 rows=10 loops=1)
Sort Key: tt.ord_id
Sort Method: quicksort Memory: 25kB
-> Subquery Scan tt (cost=0.00..1.02 rows=10 width=520) (actual time=0.057..0.184 rows=10 loops=1)
-> Limit (cost=0.00..0.92 rows=10 width=283) (actual time=0.052..0.139 rows=10 loops=1)
-> Index Scan using idx_order_orders_dat on orders (cost=0.00..122.14 rows=1332 width=283) (actual time=0.047..0.095 rows=10 loops=1)
Total runtime: 12.081 ms
(7 rows)

Все работает

sitepumper.ru=# select version();
version
----------------------------------------------------------------------------------------------
PostgreSQL 8.3.7 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.3.real (Debian 4.3.3-5) 4.3.3
(1 запись)

Koshak (not verified) - 14/Май/2009 11:40

Они возможно взяли это от мускула. так как там алиасы не так важны .

а в постгресе она раком встает если алиасы не делать при подЗапросах

lexa - 14/Май/2009 11:44

Постгрес просто не может два order by в одном запросе, как и велит ему стандарт (в каждом подзапросе свой - может, конечно)

А в MySQL, вероятно, "у меня все работает", я же ругаюсь на то, что Drupal core ни одна скотина не тестирует с постгресом по-настоящему, несмотря на то, что совместимость с оным постгресом заявлена вслух

lamantyn (not verified) - 14/Май/2009 19:59

Вообще-то, за использование embedded sql (вместо stored procedures) нужно "программистов" гнать ссанными тряпками, пиццу развозить.

bowhill (not verified) - 15/Май/2009 02:24

Из развозчиков пиццы их уже уволили.

lexa - 15/Май/2009 02:45

Это вопрос открытый. В рамках одного большого проекта с контролируемой инфраструктурой - да, наверное да, плюсов больше чем наоборот.
Ну, кроме, пожалуй процедуры атомарного апдейта этих самых stored proc на большом количестве серверов (помнится, я какие-то ужасы от скайпа про это слышал, но может и путаю).

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

Андрей Постников (not verified) - 06/Июл/2009 16:32

обнаружилась более сложная роблема - в pg8.3 отключено преобразование типов по умолчанию, похоже теперь нужно делать кучу своих create cast.

по поводу данной грабли - слишком мало пользователей posgtre, чтобы протестировать данный баг, но, думаю, 10th of July 2009 он будет исправлен http://geek.joshwaihi.com/content/drupal-code-sprints-postgresql

Процесс таков, что сначала изменения вносятся в HEAD (drupal 7) а потом уже портруются в предыдущие версии

_slw (not verified) - 11/Окт/2009 23:09

а шо делать с таким
===

* warning: pg_query() [function.pg-query]: Query failed: ERROR: value too long for type character varying(255) in /usr/local/www/drupal6/includes/database.pgsql.inc on line 139.
* user warning: query: INSERT INTO locales_source (location, source, textgroup) VALUES ('Enter PHP code to perform additional validation for this form. Include the <?php ?> tags. $form_id and $form_values are available variables. If validation fails, use the form_set_error function to prevent the form from being submitted. Use the same syntax as a _validate function used in the Forms API', 'Enter PHP code to perform additional validation for this form. Include the <?php ?> tags. $form_id and $form_values are available variables. If validation fails, use the form_set_error function to prevent the form from being submitted. Use the same syntax as a _validate function used in the Forms API.', 'default') in /usr/local/www/drupal6/includes/locale.inc on line 1368.
* warning: pg_query() [function.pg-query]: Query failed: ERROR: value too long for type character varying(255) in /usr/local/www/drupal6/includes/database.pgsql.inc on line 139.
* user warning: query: INSERT INTO locales_source (location, source, textgroup) VALUES ('Enter PHP code to perform additional processing for this form (after the validation). Include the <?php ?> tags. $form_id and $form_values are available variables, use the same syntax as a _submit function used in the Forms API.', 'Enter PHP code to perform additional processing for this form (after the validation). Include the <?php ?> tags. $form_id and $form_values are available variables, use the same syntax as a _submit function used in the Forms API.', 'default') in /usr/local/www/drupal6/includes/locale.inc on line 1368.
* warning: pg_query() [function.pg-query]: Query failed: ERROR: duplicate key value violates unique constraint "locales_target_pkey" in /usr/local/www/drupal6/includes/database.pgsql.inc on line 139.
* user warning: query: INSERT INTO locales_target (lid, language, translation, plid, plural) VALUES (0, 'ru', 'Использовать php для дополнительной обработки. Включите <?php ?> в код. Доступные операторы: $form_id и $form_values', 0, 0) in /usr/local/www/drupal6/includes/locale.inc on line 1370.

===

lexa - 15/Окт/2009 15:45

В общем случае - удавиться.

Т.е. MySQL тихо-тихо трункейтит слишком длинные строки, а постгрес - ругается.

В частном случае
1) в семерке (Drupal 7) это место переделали, все поля с длинными строками стали TEXT, но бэкпорта в Drupal 6 вроде еще не было.
2) В наиболее доставших местах (логи, перевод) я ручками длину поля увеличил до килобайта-двух (через alter table) и успокоился.

Где именно увеличивал - не помню.

andypost (not verified) - 02/Фев/2010 00:34

Наконец удалось пропихнуть сие в ядро 6ки, теперь будет работать без патчей. Хорошо бы проверить сие еще на 8.4 но думаю проблем не будет http://drupal.org/node/396388

По поводу урезания длинных строк патч давно ожидает своего принятия http://drupal.org/node/221020

ZhN (not verified) - 27/Авг/2010 11:24

ссылка на твиттер битая

lexa - 27/Авг/2010 17:25

Спасибо, поправил.

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