логин: 
Другие записи за это число:
2011/08/06 - Как поменять дефолтные настройки для заметок блога?
<< предыдущая заметкаследующая заметка >>
06 августа 2011
Посоветуйте. Не могу принять решение.

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

1) Постить заметку по наступлении указанного числа XXXX/XX/XX.
2) Постить заметки из этой серии по определенным дням (напр. в пятницу).
3) Постить заметку (очередную или выбранную случайно) в случае N-дневного отсутствия постов (вариант: постов с тем же тэгом).
4) Есть еще какие-то идеи?

Это был первый вопрос: какие еще применения (и условия срабатывания) отсроченных постов вам бы хотелось видеть?

Вопрос второй — архитектурный.

Во-первых, нужна особая опция, чтобы подготовленную для постинга заметку нельзя было раньше времени ни увидеть, от отредактировать, ни отменить.

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

— У «заготовленных» заметок кучи своих специфических полей для срабатывания постинга, по которым надо делать быстрый поиск MySQL (значит, они должны быть индексами). На хрена это в общей базе?

— Общую базу придется ограждать от попадания в выдачу (оглавление, результаты поиска) заметок скрытых. А это скажется на быстродействии.

— Придется принимать специальные меры, чтобы менять num заметки — иначе по num (а его можно найти в коде страницы) можно понять, свежая это заметка или созданная в то время, когда сквозная нумерация num была того же порядка. А это лишние дырки в num.

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

Какие у вас мысли?

<< предыдущая заметка следующая заметка >>
пожаловаться на эту публикацию администрации портала
архив понравившихся мне ссылок
Оставить комментарий
Windows Opera
1
2
[email protected] (wott.info)
Править надо в консерватории.

Такие фичи делаются постингом в будущем. Слова о быстродействии - как всегда преждевременная эаку... ой простите, оптимизация.

Параметры, произвольные при этом храняться отдельно и легко линкуются к посту join-ом.

А размышления о num - это вообще за гранью. автосохранение, аттачи, перепостинг на другого автора и прочие фишки легко рушат стройный ряд нумерации, которая вообще не имеет значения когда есть permalinks, которые есть у любого порядочного блога.

Ах, да, фичи из списка в начале делаются плагинами. Любые.
Linux Firefox
 Москва
3
0
Не нахожу вообще никакого смысла в том, что вы сейчас написали.

Фичи делаются плугинами - что такое плугин? Подключаемая часть кода? Значит, плугин я и делаю, о нем и речь. Спасибо, что разъяснили, мир засиял красками.

"Постинг в будущее" - это определение подходит только для случая номер 1 из тех, что я перечислил. Есть огромный класс других жизненных ситуаций, для которых дурацкий жжный "постинг в будущее" не работает. Самый простой пример: в журнале Темы, когда он вне доступа регулярно раз в сутки все равно появляются заметки из базы, которые он набил кучей на будущее давным-давно, типа "Какой рукой вы причесываетесь?" Вы полагаете, это не робот постит из его базы, а лично Тема перед поездкой забил на среду в 15:00 опубликовать?

Ну а ваши размышления о num действительно за гранью. Какое автосохранение? Какой перепостинг? О чем это всё?! У меня в базе заметке присваивается автоинкрементный num, с которым отныне работают все системные обращения движка к заметке. Потому что идиотизм в движке и всех его таблицах, где нужно сослаться на заметку, хранить адрес заметки по ее буквенному адресу /arhive/raznoe/2011/poezdka/fotki/italia/vasya_na_pizanskoi_bashne.html При чем тут ссылки на другого автора?

Вы явно не поняли, о чем вообще речь.
Linux Firefox
0
0
[email protected] (sunchaser.info)
Архитектурно лучше в одной. А о быстродействии — просто сделать индекс по IsVisible или DateShow или как там это будет. а лишнее условие в выборке — это доли копеек, если EXPLAIN тот же
Linux Firefox
 Москва
0
0
Мне не хочется вводить в таблицу (на 99.99% состоящую из опубликованных за долгие годы заметок) лишние поля (и их лишние индексы!) ради того, чтобы по ним каждые полчаса отрабатывал cron.

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

Например - я хочу, чтобы все заметки тэга "письма в стихах" формировались по своему шаблону - предварялись стандартным вступлением, имели стандартный заголовок с очередным номером (номер я при написании еще не знаю, потому что "письмо" будет выбрано из загашника по случайному закону).
Linux Safari Chrome
 Зеленоград
0
0
Д.С. (#1018858)
Возможно, имеет смысл хранить заготовленные для публикации заметки в таблице с уже опубликованными заметками, а специфичную информацию о том, как и когда ту или иную постить - в отдельной таблице. Тогда можно будет привязывать эту информацию не к отдельным заметкам, а к тэгу, например.

Что касается нумерации - вряд ли это очень большой минус. Однако, если это вас беспокоит, можно сделать для секретности псевдономер, зависящий от даты и времени публикации заметки, что-нибудь вроде base64_encode(time()).
Linux Firefox
 Москва
1
0
Вопрос с прайваси нумерации решается просто: удалить заметку и создать ее же заново. Псевдономер невозможен - в движке масса индексированных таблиц, где используется номер заметки в виде числа. Одна лишь таблица посещений за год занимает мегабайт 300. Замени int(11) на base64_encode - снизится и быстродействие (индекс по varchar), и таблица вырастет втрое.

Вопрос не в этом. Если у меня перед написанием поста была неясность, то когда я все сформулировал, я не вижу ни одной причины хранить Полуфабрикаты Заметок Которых Нет в той же базе, где лежат Готовые Заметки.

Какая причина может быть? Механизмы обращения к ним и запросы MySQL принципиально разные - не существует запроса, когда надо найти информацию и среди тех и среди этих одновременно. Поля данных у них разные. У заметок блога - свои специфичные поля и индексы, у заготовок - свои. Даже поля Body и Header у них - и те разные (о втором случае речь идет скорее о Body_template и Header_template), без специальной переработки одно в другое не копируется.

Только проблема с окошком редактирования? Да скопирую я код окошка редактирования и будет он работать с другой таблицей. Или внесу в код пару строк, чтобы он работал в двух разных режимах.
Windows Firefox
0
0
zencd
/* А это скажется на быстродействии. */

Обязательно скажется - быстродействие не ухудшится. Потому что выбирать из двух таблиц гораздо тяжелее чем проверить флажок при выборке из одной. Да и не зря же индексы придумали - как раз чтобы люди не пытались испортить архитектуру ради скорости.

Новые поля имхо лучше вынести в отдельную таблицу, если они не сильно вписываются в основную:
table articles_autoposting_params (
int id,
int article_id references(article.id),
param1,
param2
)

Не очень понимаю что такое num - 2011/08/06_1? Вобще, раз уже в системе появляется отложенность и есть желание сохранить прежнюю схему формирования урлов, то стоит иметь уникальный id заметки для чисто внутреннего обращения и ещё, в дополнение к дате, ввести дополнительный номер для различения заметок в рамках суток (variation). id заполнять при создании заметки, variation - при публикации. При таком подходе не надо будет ничего переписывать (брр).
Linux Firefox
 Москва
0
0
Размышляя о быстродействии MySQL важно понимать, кто именно делает какие запросы, и как часто.

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

Другой запрос делает движок при КАЖДОМ посетителе. И здесь добавить к запросу лишнее условие AND `autopost`='no' - это малая нагрузка, но ничем не оправданная.

PS: num это и есть id. Дополнительно нумеровать заметку в сутках неправильно. То есть, это правильно ровно настолько, насколько 2011/08/06_2 больше 2011/08/06_1 - такую нумерацию движок предлагает автоматически при записи новой заметки. Но при этом я знаю, что если я напишу заметку 2011/08/06_Samoe_Vazjnoe - она будет верхней (по порядку букв), и при запросе последней страницы движок выведет именно ее. Даже если я затем добавлю за то же число 2011/08/06_3 Это удобно. Ведь вставить "неглавную" заметку дня до главной заметки 3 я бы не смог - при нумерации роботом она бы стала заметкой 4, и хоть расшибись, наверху.
Windows Firefox
0
0
zencd
Понял - во второй таблице заметки будут храниться временно, и постепенно перекочёвывать в основную.

"Лишнее условие" autopost=FALSE (эффективнее сравнивать с true/false, а не со строками) действительно лишнее. А вот условие published=TRUE вполне уместно. Неужели у вас уже не реализована возможность недеструктивно изъять заметку из эфира? Думаю что как раз реализована; а если так, то этот флажок и так уже должен проверяться. Роботу остаётся только выставлять его в true.
Windows
 Киев
3
0
lesha (#437416)
Если админ не появляется более Н дней запостить "вероятно я умер" и завещание. :)
Nokia-E90 Safari
 Москва
3
0
lleo Nokia E90 (#909087)
Именно так. Либо - обнародовать тот компромат, ради которого угрожали.
Windows Safari Chrome
0
0
Леонид, я правильно понимаю что всё это хозяйство находится на одном сервере в одной базе данных? У меня нет ответов, а есть пара вопросов. Что делается с автоматически "запощенной" заметкой? Она ведь каким-то образом должна перекочевать в основную таблицу? И вот ещё: планируется ли у таблицы с неопубликованными ещё заметками какой магический "change" или "version" контроль, или эта таблица нужна просто как временное хранилище перед постингом, а собственно рабочая площадка для работы над заметками находится в дгругом месте?
Nokia-E90 Safari
 Москва
0
0
lleo Nokia E90 (#909087)
Да, совершенно верно: все хозяйство на одном сервере, а таблица заготовок - лишь временное хранилище. К которому имеет смысл затруднять доступ, а не облегчать.
Windows Safari Chrome
0
0
Тогда получается что редактору не надо работать с этой таблицей, и единственный фигурант которому нужен доступ, - это крон. Крон может выбрать заметку, перенести её в основную таблицу, удалить из временной таблицы итд. Фильтры можно тоже хитро запрограммировать в базе чтоб крон мог их использовать либо прямо в выборке, либо через "view".
Linux Firefox
 Москва
0
0
Совершенно верно! Я тоже так думаю!

Вот правда насчет крона как такового у меня сомнения - обычно я делаю cron.php и в кроне пускаю его как fetch (или wget) http://domain.xx/cron.php

Это дает возможность запускать cron.php на тех хостингах, где нет возможности настроить cron - либо вручную, либо в скрипте по событию. В движке таким событием является новый комментарий.
Windows Safari Chrome
0
0
Если ваш MySql сервер весрсии 5.1 или выше, то вы можете воспользоваться встроенным механизмом "event scheduler". В обших чертах, это то же самое что и crontab (или "cron job") под UNIX, - только на уровне и в пределах самой базы MySql. Вот простой пример (если что не понятно - спрашивайте, я переведу на русский):

use test
show variables like 'event_scheduler';
## Если event_scheduler = OFF то надо его "включить": SET GLOBAL event_scheduler = ON; ##

create table mytab(id int NOT NULL auto_increment, num int, value varchar(50),primary key (id));
insert into mytab (num, value) values (55,'Our first value');
commit;
select * from mytab;

###DEFINE PROCEDURE MYPROC###
delimiter //
CREATE PROCEDURE myproc(p1 INT)
BEGIN
SET @x = (select max(num) + 1 from mytab);
if @x is null then SET @x = 1; end if;
insert into mytab (num,value) values (@x,concat('Value_',@x,' at ',DATE_FORMAT(NOW(), '%d-%m-%Y %H:%i:%s')));
commit;
END;
//
delimiter ;

###Test MYPROC (this call should insert a record into mytab)###
CALL myproc(1);
select * from mytab;

###DEFINE "CRON JOB" EVENT REPEATING EVERY MINUTE###
CREATE EVENT mycron
ON SCHEDULE EVERY 1 MINUTE
DO
CALL myproc(1);
###
select * from mytab;

#...etc...
##(this will show that a process exists for "event_scheduler"):##
SHOW PROCESSLIST\G

###CLEAN UP###
drop event mycron;
drop procedure myproc;
drop table mytab;
Linux Firefox
 Москва
0
0
Ох... Спасибо, общий смысл я вроде понял.

Но пока не представляю, как это применить в движке.

Сейчас ситуация такова, что не очень важно само время срабатывания - нет таких задач, которые следует выполнить ровно в 15:04.

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

Для грамотно настроенного хостинга предполагается cron, для всех остальных - движок срабатывает по событию нового комментария. Это достаточно надежный показатель - чем популярнее площадка, тем больше комментариев, и тем чаще надо следить за хозяйством.

А вот MySQL версии 5.1 может не быть.
Windows Safari Chrome
 Австралия
0
0
Версия 5.1 или новее. У меня, к примеру, версия 5.5.9.
Как раз для автопостинга это должно подойти. Если я понимаю правильно, то посетителям новая заметка становится доступна как только она добавлена в основную таблицу. То есть достаточно перенести подготовленную заметку из временного хранилища - назовём эту временную таблицу "STAGING", в основную таблицу - назовём её "PROD". Допустим у вас в MySql заготовлена процедура MOVE_ME которая делает выборку из STAGING, определяет какую именно заметку надо опубликовать, копирует всё что надо из STAGING куда надо в PROD, удаляет оригинал из STAGING, делает commit. По идее это и есть процесс постинга. Теперь, чтобы сделать автопостинг, скажем, раз в день в 1:30 am, достаточно в MySql создать event - назовём его PUBLISH_ME (это и есть эквивалент крона) который сам по себе будет просыпаться каждую ночь в 1:30 am, и выполнять процедуру MOVE_ME.
###
CREATE EVENT IF NOT EXISTS PUBLISH_ME
ON SCHEDULE EVERY 1 DAY
STARTS DATE_ADD(DATE(SYSDATE()) + 1, INTERVAL '1:30' HOUR_MINUTE)
DO
CALL MOVE_ME;
###
С точки зрения базы данных, лучше и не придумаешь. В базе, кстати, можно программировать и в triggers, - например выполнять аудит или ещё какую надо процедуру каждый раз когда заносится новая запись в таблицу, или обновляется, или удаляется - возможностей до фига, они ограничены разве что воображением разработчика.
Nokia-E90 Safari
 Москва
0
0
lleo Nokia E90 (#909087)
Да, но постинг заметки - это не перенести из одной таблицы в другую.

Здесь, как минимум, должно работать условие постинга. Например: если сегодня пятница, то выбрать в таблице заготовок случайным образом одну из тех заметок, что подготовлены для публикации по пятницам.
Windows Safari Chrome
0
0
Не вижу проблемы, - пусть это будет хоть третий понедельник каждого четвертого месяца после полудня китайского времени. Придумайте механизм фильтров с настройками и вам все карты в руки :)
Linux Firefox
 Москва
0
0
А завтра придут эти ужасные зануды и начнут просить переделать движок под Sqlite... ;(
Windows Firefox
0
0
murrmax (#417977)
отдельную таблицу backposts, в момент срабатывания события переносить в основную с присвоением num и удалять (как вариант, сбрасывать флажок) из backposts
Windows Firefox
0
0
murrmax (#417977)
аргумент за разделение - не столько на быстродействие нужно смотреть, сколько на общий подход к написанию кода - если "скрытые" заметки будут у вас в той же таблице, всегда будет вероятность, что в какой-то выборке вы забудете отфильтровать скрытые записи и будет утечка инфы.
Windows Firefox
0
0
murrmax (#417977)
да, кстати, Брэд Фицпатрик писал в свое время, что номера постов в ЖЖ они немножечко рандомизируют, как раз чтобы юзеры не прочухали, были ли какие-то скрытые посты за это время, например, или нет. это как бы не совсем про ваш вопрос, но тоже можно принять на вооружение

всего комментариев: 26

<< предыдущая заметка следующая заметка >>