Seditio -> Drupal6

Главные вкладки

Аватар пользователя fu7ur3 fu7ur3 12 декабря 2009 в 21:55

Привет всем.
Прошу помощи. Я новичек в Drupal. Решил перевести сайт с SeditioCMS на Drupal6. Вроде как разобрался с базой друпала. Перенес пользователей и ветки форума (в node) + комменты. Возникает следующая ошибка. Когда в трекере смотришь список обсуждений, то все правильно отображается. А если выбрать "Мои публикации" то показывает все подряд (не выбрирает только то что запостено от пользователя. Подозреваю что в какую-то таблицу не занес значения, только вот никак не могу найти в какую. Пробовал модуль tracker2, он вообще ничего даже в трекере не показывает.

Ниже привожу список таблиц котрые трогал:

1. Перенос пользователей + данные их профилей.
users
profile_values

2. Перенос тем форумов (в node).
node
node_comment_statistics
node_revisions
history

3. Перенос постов.
comments

Прошу знатоков подсказать где я ошибся. Любые мысли приветсвуются. Спасибо за внимание Smile

Комментарии

Аватар пользователя fu7ur3 fu7ur3 12 декабря 2009 в 22:55

Что значит "по каждому пользователю" ?
Я заполнил поле uid в таблице node. Если бы не заполнил, то ноды вы вообще не показывали имена тех кто их cоздал. А все это работает.
обьясните может я что-то перепутал.

PS: Есть ли какие-либо средства для конвертации из двига в двиг. Нарпример экспортировать в xml а потом через какой-нить агрегатор подцепить. Или иначе. Сейчас у меня просто скрипт на perl который делает много выборок и вставок..

Аватар пользователя PVasili PVasili 12 декабря 2009 в 23:02

INSERT ... SELECT .... FROM
Uid должен быть у каждого пользователя свой. Посмотрите структуру таблиц. Я вам дал ссылку. Там все понятно нативно.

Аватар пользователя fu7ur3 fu7ur3 12 декабря 2009 в 23:10

>Uid должен быть у каждого пользователя свой. Посмотрите структуру таблиц. Я вам дал ссылку. Там все понятно нативно.

Вы правы, он уникальный же) Я знаю это.
В общем я видимо плохо проблему описал. Сейчас работает отображение нод со всеми их комментами. Отображаются профили пользователей и их данные. Это ок. Если отключить Tracker2 и использоваться стандартный трекер, то он нормально показывает список обсуждений. Ежели выбрать пункт (в трекере) "мои публикации" то каша какая-то. Тут косяк.
Как узнать к каким таблицам/полям обращается двиг, когда нажимаешь на кнопочку "мои публикации"?

Аватар пользователя fu7ur3 fu7ur3 12 декабря 2009 в 23:27

Думаю не все так просто. Есть потому что таблиц уж очень-то много. Например 4штуки надо только чтобы ноду показать. Тут жду такого-же подхода. Кеш не включен, хотя может оно тут в BLOB'ах хранит. Что-то засомнивался.
uid в нодах и комментах выставлен правильно. Куда еще посоветуете глянуть ?

Аватар пользователя fu7ur3 fu7ur3 12 декабря 2009 в 23:31

>А как вы узнали какие поля надо заполнять при импорте БД?

мне база друпала показалась очень лаконичной.
nid - node id
pid - parent id
cid - comment id
uid - user id

тут все понятно сразу. Потом глянул Drupaler.ru и убедился что правильно понял.

Аватар пользователя Dan Dan 13 декабря 2009 в 0:32

"fu7ur3" wrote:
тут все понятно сразу. Потом глянул Drupaler.ru и убедился что правильно понял.

Да, лаконична и понятно, но не стоит думать, что одного взгляда достаточно.
Сделайте дамп базы, создайте ноду, сделайте дамп и сравните с предыдущим - это самый верный способ узнать что меняется в БД при изменении контента. То же самое - для остальных сущностей. Я уверен, что Вы пропустили несколько таблиц.

Аватар пользователя gorr gorr 13 декабря 2009 в 15:26

Проверьте таблицу node_revisions, там если у Вас всего по одной версии нодов, то vid=nid для всех записей, также и uid значения для таблиц node и node_revisions должны быть одни и те-же. Хотя если проблемы с трекером в профиле только, то скорее неверно занесены данные в comments и node_comments_statistics, потому что в трекере запрос делается вот так:
<?php
$sql = 'SELECT DISTINCT(n.nid), n.title, n.type, n.changed, n.uid, u.name, GREATEST(n.changed, l.last_comment_timestamp) AS last_updated, l.comment_count FROM {node} n INNER JOIN {node_comment_statistics} l ON n.nid = l.nid INNER JOIN {users} u ON n.uid = u.uid LEFT JOIN {comments} c ON n.nid = c.nid AND (c.status = %d OR c.status IS NULL) WHERE n.status = 1 AND (n.uid = %d OR c.uid = %d) ORDER BY last_updated DESC';
$sql = db_rewrite_sql($sql);
$sql_count = 'SELECT COUNT(DISTINCT(n.nid)) FROM {node} n LEFT JOIN {comments} c ON n.nid = c.nid AND (c.status = %d OR c.status IS NULL) WHERE n.status = 1 AND (n.uid = %d OR c.uid = %d)';
$sql_count = db_rewrite_sql($sql_count);
$result = pager_query($sql, 25, 0, $sql_count, COMMENT_PUBLISHED, $account->uid, $account->uid);
?>
То есть либо n.uid не совпадает со значением c.uid либо вот здесь n.nid = l.nid что-то не так, либо это выражение дает глюк: GREATEST(n.changed, l.last_comment_timestamp). Другие таблицы не задействованы.

Аватар пользователя PVasili PVasili 13 декабря 2009 в 16:14

"RxB" wrote:
которые парят мозг, в тот момент, когда есть API
аналогично не понимаю извращения с API когда есть 1 SQL запрос Wink

Аватар пользователя Dan Dan 13 декабря 2009 в 17:14

"fu7ur3" wrote:
Включил логирование sql запросов, пробую разобраться в какие таблицы оно еще обращается.

Умрёте это лог смотреть.

"gorr" wrote:
Проверьте таблицу node_revisions, ...

Да, по идее, только users, node, node-revisions, comments, node_comments_statistic задействованы в вашем наборе данных. Но есть один подводный камень: ветви комментов. Я обновлял ветви таким кодом:
<?php
$res = db_query(" SELECT * FROM {comments} WHERE thread = 'false_thread' ");

while( $row = db_fetch_array($res)){
$thread = int2vancode($row['cid']) .'/';
printf("thread = '%s' --cid = %d", $thread, $row['cid'] );
db_query("UPDATE {comments} SET thread = '%s' WHERE cid = %d LIMIT 1", $thread, $row['cid'] );
print('
');
}
?>
false_thread - это флаг который я использовал в таблице comments, дабы отличать существующие комменты от тех, что я добавляю.
За код не отвечаю - не факт, что это конечная версия.

"RxB" wrote:
для комментов есть comment_save(). Я искренне не понимаю людей, которые парят мозг, в тот момент, когда есть API

"PVasili" wrote:
аналогично не понимаю извращения с API когда есть 1 SQL запрос ;)

Если вы делаете одноразовый импорт и существующие модули не могут корректно импортировать данные, то логично воспользоваться SQL-запросом, контролируя весь процесс.
Если же вам нужно периодически программно добавлять записи, то лучше это делать с помощью API, воспользовавшись функцией drupal_execute (это более современный и универсальный вариант, нежели node_save, comment_save, taxonomy_term_save и т.д.).