Ну он ж в табличке
Ну так если мне не хватает памяти, чтоб прочитать текущую табличку и записать ее в файл, то то же самое потом и с той новой табличкой может стать
Aliaksandr
Aliaksandr
Скажут мол больше 10 тыщ она не тянет и все ))
Anonymous
Не тысяч, а записей
Aliaksandr
Понятно, что все за наилучший вариант: чтоб работало быстро и ненакладно. Но в реальной жизни между вариантами "работало, но тяжеловато" и "не работает вообще" вряд ли многие выберут второй
Pathologic
closure table и позволяет в теории обходится без алиаслистинга
Anonymous
Я не защищаю это решение, не смотря на то что я его впиливал, так как я его не тестировал на больших данных. И не могу быть уверенным на 100% в его правильности
Anonymous
closure table и позволяет в теории обходится без алиаслистинга
Теоретически да и даже можно переписать что-то типа getParentIds на его и в целом грохнуть aliaslisting
Anonymous
Но на этом листинге много чего завязано
Aliaksandr
Вопрос в том, чтобы оно опять не стало узким местом
Anonymous
Нужно нагенерить большую таблицу и проверить
Anonymous
На сайте с 60к ресурсов не упало
Anonymous
И в целом ничего не сломало
Pathologic
главные недостатки - чем больше вложенность, тем больше записей в таблице связей и сложности с перемещением ветвей дерева
Aliaksandr
Ну вот у меня сейчас 600к товаров, под 90к папок и 5.5 млн отзывов (в отдельной таблице). С пустым siteCache.idx работает, а создать его не может
Aliaksandr
aliasListing только для папок, естественно
Pathologic
ну вот ты мог и товары в отдельной таблице хранить
Pathologic
тогда и папок стало бы сильно меньше
Anonymous
Aliaksandr
Так я мож и на ларе делать, но мы же все на эво, потому что любим дерево ))
Pathologic
так в твоем случае дерево не нужно
Pathologic
потому что никто не будет даже его открывать
Aliaksandr
Дерево отлично открывается
Aliaksandr
3к категорий в папке каталог, в категорях эти 80к брендов (по среднему 30-40 штук в ветке), в этих 80 к брендов 600 к товаров (тоже по 10-20 в ветке)
Aliaksandr
И сохраняется все с выпиленным листингом за пару сек в админке
Aliaksandr
Проблем нет, кроме этой карты кэша)
Pathologic
ну еще бы
Pathologic
он ведь создается заново при каждом чихе
Aliaksandr
Ну вот я его на крон выкинул, но и там не могу создать, пока не разбирался почему, но скорее всего база не может отдать сразу весь запрос
Aliaksandr
Падает на бегете крон с кодом 255, что на русском означает "хер знает, что там пошло не так"))
Aliaksandr
Хотя точно рабочий, проверял на малых дозах
Pathologic
перенеси товары в другую таблицу
Aliaksandr
Так смысла нет в этих телодвижениях. Чтобы кэш той же главной сделать памяти хватает, а потом она уже оттуда за 0.1 сек запросто выстреливает. Даже при пустом siteCache.idx -файле
Aliaksandr
Хотя там конечно страница пиздец, ссылок на ней наверно тысяч 5 ))
Pathologic
так а чего бы не хватать памяти на кэш страницы
Aliaksandr
Ну я имею в виду на создание
Pathologic
так там памяти килобайты нужны ((:
Pathologic
в теории у тебя еще может с файловой системой возникнуть проблема
Aliaksandr
Не всякую страницу килобайтами памяти создашь)
Aliaksandr
Короче нигде проблем нет, кроме алиаслистинга в файле кэша
Aliaksandr
Файловая пофиг, конечные страницы по просьбе заказчика не кэшируются, потому что слишком много места жрут, дорого ))
Aliaksandr
Там и так все быстро работает, с его слов
Pathologic
ну разговоры о том, что алиаслистинг не нужен, давно велись
Aliaksandr
вот конечная - хрена там кэшировать )) <!-- Mem : 4 mb, MySQL: 0,0120 s, 76 request(s), PHP: 0,0222 s, total: 0,0342 s, document from database. --> - и то запросы половину от того, что я вообще весь кэш выпилил (сниппеты, плагины и системсеттинг)
Pathologic
ну это мог и не выпиливать, оно погоды не делает
Aliaksandr
а так получается 100-150 кило на страницу кэша, на 10 страниц мегабайт, на 10 тыщ - гигабайт, на 600 тыщ товаров - уже 60 гигов одного кэша (плюс картинки из пхптумбы))
Aliaksandr
ну это мог и не выпиливать, оно погоды не делает
это я скорее всего назад впилю, просто пробовал как оно будет вообще без всего
Pathologic
вообще ты можешь использовать мемкэш
Pathologic
и кэшировать туда страницы
Aliaksandr
да там шаред с соответствующим бюджетом, не было печали, еще серьезно заниматься кэшем, когда и так все более, чем приемлемо ))
Aliaksandr
одна беда - aliasListing на 80 тыщ папок )))
Pathologic
на шаредах бывает мемкэш
Aliaksandr
вот на 2.0 наверно так легко уже работать не будет. вряд ли там кэшируется в блейде результат makeUrl )
Aliaksandr
будет гонять что дурной каждый раз эту функцию столько раз, сколько встретит, я так понимаю
Pathologic
ну так ты можешь вставлять [~~], а потом парсить
Pathologic
но там проблема что без алиас листинга много запросов чтобы урл сделать
Pathologic
так что тут тебе и пригодился бы кложур
Aliaksandr
я имею в виду, когда тем же доклистером сразу урл получили и закэшировали результат вместе с урлом - это одно, а когда взяли SiteContent, че-то там получили объект, прокинули его в блейд и уже там в фориче делаем makeUrl - то может случиться коллапс, при таком подходе )
Pathologic
кстати для 1.4 был плагин от Жени, чтобы построить таблицу связей
Pathologic
https://github.com/AgelxNash/ClosureTable
Aliaksandr
Как они там в своих ларавелях нормально строят деревья каталогов произвольной вложенности хз, нигде эта скользкая тема особо не попадалась мне
Pathologic
ну так вариантов много может быть
Aliaksandr
Везде на уровне "вот раздел новостей - вот в нем новости")
Pathologic
ну это как с тестами, везде "давайте проверим, что 2+2 = 4"
Pathologic
может это считается настолько простой вещью, что и говорить нечего ((:
Pathologic
вдруг любой школьник сейчас знает как деревья в базе хранить, а мы тут тупим
Aliaksandr
Скачиваешь композером пакет для хранения деревьев в базе и все дела ))
Андрей [aharito]
Вопрос глупый, но важный ))
Я так понимаю, что в структуре БД Эво нет внешних связей между таблицами?
И все связи типа каскадного удаления осуществляются через PHP скрипты?
То есть в принципе, добавив на локалке какой-то ТВ, я могу грохнуть на хостинге таблицы evo_site_tmplvars, evo_site_tmplvar_access, evo_site_tmplvar_contentvalues, evo_site_tmplvar_templates и импортнуть их с локалки? или нет?
Как деплой удобнее делать?
Dmytro
Вопрос глупый, но важный ))
Я так понимаю, что в структуре БД Эво нет внешних связей между таблицами?
И все связи типа каскадного удаления осуществляются через PHP скрипты?
То есть в принципе, добавив на локалке какой-то ТВ, я могу грохнуть на хостинге таблицы evo_site_tmplvars, evo_site_tmplvar_access, evo_site_tmplvar_contentvalues, evo_site_tmplvar_templates и импортнуть их с локалки? или нет?
Как деплой удобнее делать?
Тут основной вопрос что делать когда паралельно наполняют сайт и ты что то хочешь задеплоить просто так удалять нельзя получится что затреш контент же
Nikolay
Nikolay
с картинок
Sasha
Господа, так все-таки подскажите, что я делаю не так. Подключил к formlister форму через b_file и в этом шаблоне формы не доступен $documentObject ?
EVO bot Лёшка
Господа, так все-таки подскажите, что я делаю не так. Подключил к formlister форму через b_file и в этом шаблоне формы не доступен $documentObject ?
Читай документацию ©(Pathologic)
http://docs.evo.im/03_extras/formlister.html
Sasha
делаю <form action="{{ $modx->makeurl($documentObject['id']) }}" method="post"> а там получается /0
print_r($documentObject); вообще ничего не дает, пустое место
Sasha
вообще кто скинет правильный пример формы в файлах - буду благодарен. А то что-то не понимаю, не заводится
Дмитрий
Прокидывал все через defaults в форму