А-Парсер и Пандора!
- Автор темы Topper
- Дата начала
- Статус
Я какую то такую конструкцию в дорах юзаю. APARTICLE не использую.
Но последнее время чет вылетать стали. ( Так что конструкцию меняю...
Хотелось бы улучшить чекалку картинок на существование, т.к. процентов в 50 все равно вставляет битую ссылку.
Но последнее время чет вылетать стали. ( Так что конструкцию меняю...
Хотелось бы улучшить чекалку картинок на существование, т.к. процентов в 50 все равно вставляет битую ссылку.
+ за идею. APARTICLE не использую.
Есть еще пожелание сохранять только уникальные предложения и титлы, а то часто бывают повторы. И еще, например, при использовании нескольких макросов APTEXT на странице, может вывести одно и то же предложение.
Есть еще пожелание сохранять только уникальные предложения и титлы, а то часто бывают повторы. И еще, например, при использовании нескольких макросов APTEXT на странице, может вывести одно и то же предложение.
APARTICLE использую активно. Без него теряется всякий смысл. Зачем мне огромное количество текста, когда есть конкретная статья под даный запрос? Topper, пожалуйста, низачто не удаляй APARTICLE
Если уже делать 1 ключ - 1 файл, то в самом файле можно расставить маркеры-разделители, по которым можно будет видеть границы всей статьи. Так можно сохранить APARTICLE и работать с одним файлом. Тайтл вроде также парсится с текстовкой
программа развивается и мне нужны апдейты, как и всем вам.
ну ты не юзаешь и тебе не нужна коллекция - а я юзаю - и каждый раз парсить и ждать по двое трое суток пока спарсит что то смысла не вижу - в особенности когда по ключам ты уже входишь ... и получается каждый раз при каждой пакетке есть шанс себя спарсить ...
у меня активно по 10 000 пакеток создаются - по твоему мне прийдется их генерить года пол .... - это если без сохранений - если с это за 5-ть суток происходит ...
ничего не имею против, нет так нет, я же не призываю выпилить функционал чисто под свои потребности.
Topper, а на какой процент прирост скорости ожидается в работе ? если значительно, то заманчиво конечно.
Но всеми руками за чекбокс с режимами.
Можно и без миграции ради модернизации.
Я хотел выяснить есть ли пользователи у макрос APARTICLE.
Вижу теперь что есть и что он нужен. Поэтому можно перейти в вариант хранения данных в 1 файле блоками:
{ARTICLE}текст{/ARTICLE}{ARTICLE}текст2{/ARTICLE}{ARTICLE}текст3
Или проще: текст#HESOYAM#текст2#HESOYAM#текст3#HESOYAM#текст4 или типо того.
п.с. Все помнят HESOYAM из RB ? )))
В общем макрос оставим, и миграция будет.
Вижу теперь что есть и что он нужен. Поэтому можно перейти в вариант хранения данных в 1 файле блоками:
{ARTICLE}текст{/ARTICLE}{ARTICLE}текст2{/ARTICLE}{ARTICLE}текст3
Или проще: текст#HESOYAM#текст2#HESOYAM#текст3#HESOYAM#текст4 или типо того.
п.с. Все помнят HESOYAM из RB ? )))
В общем макрос оставим, и миграция будет.
Последнее редактирование:
Topper, ну я незнаю за остальных товарищей, но лично я макрос APARTICLE так и непользую вообще, а что касаемо миграций - имхо вообще удаляю спаршенное после каждой пакетки, диск нерезиновый, невижу смысла создавать коллекцию из текстовки, легче свежего при необходимости спарсить.
Я наоборот за коллекционирование статей, т.к. жесткий диск у меня огромный, а распаршивать по новой порой очень долго, пусть уж лучше своя локальная база формируется, да и прокси постоянно покупать не охото. А так с локальной базы загенерить, идеально. Ну или допарсить по ходу дела чего нужно.
Я наоборот за коллекционирование статей, т.к. жесткий диск у меня огромный, а распаршивать по новой порой очень долго, пусть уж лучше своя локальная база формируется, да и прокси постоянно покупать не охото. А так с локальной базы загенерить, идеально. Ну или допарсить по ходу дела чего нужно.
- Статус