видимо да )

'lifetime' => 120,

120 минут всего

почему так мало?

по умолчанию так было. не трогал этот конфиг с установки

https://habrahabr.ru/post/219475/

мило

старый конечно пост. 3х летний

ок. с этим разобрался. а лара умеет сама переадресовывать на авторизацию если требуется?

угумс

хау?

Illuminate \ Auth \ AuthenticationException Unauthenticated.

Route::group(array('before' => 'admin.auth'), function() Route::filter('admin.auth', function() { if (Auth::guest()) { return Redirect::to('login'); } }); это верное решение?

мне кажется нет. мне кажется можно как то настроить auth MIDDLEWARE чтобы он перекидывал автоматом.

из коробки это есть. редиректит на /login как раз мидлваром, если не ошибаюсь

в 5.4 не хотит.

разбираюсь

в смысле? роут если закрыт мидлваром auth - должно редиректить

\Illuminate\Auth\Middleware\Authenticate

а где тут редирект? я вижу только эксепшн

роут закрыт миддлваром

вернее в контроллере прописан

\App\Http\Middleware\RedirectIfAuthenticated

вот тут вижу

в конструкторе например, как в HomeController, который из коробки создается командой php artisan make:auth?

с этим самым контроллером работает?

да

а с другим нет при точно таком же использовании мидлвара?

так, мож я чего не так говорю. у меня на сайте пока пара страниц. это авторизация (сгенеренная артисаном) дашборд и страница настроек профиля. контроллер SettingsController в конструкторе закрыт $this->middleware('auth'); я ожидаю переадресацию, но получаю эксепшн

на дашборде тоже самое в хоумконтроллере

https://paste.laravel.io/4X13D сделал свой ) работает как надо )

но правильно ли это )

редирект не туда, но не суть

странно это. проверил у себя на похожем почти голом проекте с авторизацией из коробки. пытаюсь зайти на /home не авторизованным - редиректит на /login - как и ожидалось. 5.4 версия

у меня практически голый. из одежды только 1 контроллер настроек профиля и контроллер авторизации через социлайт

мозгов больше будет в ларе поищу причины. пока в гитлаб записал фьюче рефакторинг

Вешай мидлварю на роут

А не в контроллер

ага. уже переделал

Пора бы свои курсы по laravel запилить

Laravel от нуля до чтения документации за 3 месяца

всего за 9 9990р

заебись, тебе всего 3 месяца понадобилось, чтоб понять, что ответы практически на любой вопрос есть в доках?

а чо цифры как по бусурмански разделил

если уж отделяешь, то 99 990р

либо запятую повесь

Ребят, есть бд с 3млн продуктов с перспективой расширения , лучше ли хранить всю информацию включая описания в одной таблице products или разбить все по разным таблицам и подключать их через eloquent?

В одной

Имхо

Я не шарю в оптимизации бд

Ребят, есть бд с 3млн продуктов с перспективой расширения , лучше ли хранить всю информацию включая описания в одной таблице products или разбить все по разным таблицам и подключать их через eloquent?

смотря что там в этой таблице за поля

которые не юзаются постоянно я бы выделял отдельно

название, описание, краткое описание, цифровые поля

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

ну я бы хранил в таблице id/цифровые поля, а названия (хотя вот с ними надо подумать) и тем более краткие описания отдельно вынес

Все что тебе надо редко выводить или менять вынеси

Названия то чо

Список продуктов чтоб ввести тебе придется еще 1 запрос делать

Ну или джоин

А описание товара, если оно в карточке товара в каталоге высвечивается?

Стоит ли его выносить? Они сильно таблицу загружают, там же text

Таблица пару гигов весит, если через phpmyadmin к странице обратиться , которая где-нибудь в середине, уже пару секунд обрабатывается запрос

Или в подобном случае стоит смотреть в сторону PostrgeSQL или Oracle / MongoDB? Ломаю голову, как соптимизировать работу крупной бд с кучей релейшенов

то что у тебя так долго грузится (пару секунд) говорит о явной проблеме с индексами

таблица на 15 млрд записей не сильно дольше 0.1 обрабатывается

на не самом "шустром" сервере

ERROR: S client not available

хм, я в бд не гуру, скорее всего действительно совершил оплошность, т.к у меня локалка на i7 4960HQ c 16ram

Стоит ли его выносить? Они сильно таблицу загружают, там же text

так ты выбирай не все поля, а те, которые нужны

то что у тебя так долго грузится (пару секунд) говорит о явной проблеме с индексами

не всегда проблема в индексах, еще есть прослойка в виде рендера

майадмин показывает время запроса если не ошибаюсь

а не время рендера своего

Отображение строк 1722650 - 1722674 (1722767 всего, Запрос занял 1.8659 сек.)

ну на 25 строк прям 100% ненормально

ключи, индексы установлены?

что за запрос кстати? обычный select * с лимитом на страницу нужную?

да

страшно представить что там %LIKE % выдаст

если на селекте такое

SELECT * FROM table простой))

структуру таблицы хоть покажи если ничего ужасно конфиденциального нет

Установил на ID unique , стало быстрее до 1,1 сек

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

очередная база ккнижек? )

совершенно верно) может у кого-то есть примеры таблиц под книжный ресурс, раз слово "очереденая" упомянуто?)

А накой хрен тебе дёргать из базы все 1,7 млн записей?

Рискну предположить, что те поля которые TEXT надо перенести в отдельную таблицу

Потому что они с неопределенным размером, и затрудняют произвольный доступ

ну и разумеется select * from без лимита - это дичь с такими размерами

Не надо так

Подскажите пожалуйста в laravel в поле created_at должно стоять по умолчанию on update current_timestamp или laravel сам при создании ставит текущую дату

Подскажите пожалуйста в laravel в поле created_at должно стоять по умолчанию on update current_timestamp или laravel сам при создании ставит текущую дату

Если БД создавалась через миграции - то лара сама всё это делает. Если же ручками создавали базу - нужно вручную в БД установить дефолтное значение

видимо, я проглядел изначально, что я без лимита дергал и поэтому такая скорость была, но если вернуться к вопросу о разделении, стоит ли разделять глобально? к примеру, у меня есть поля url книги и url автора для реализации SEO ссылок. сделать таблицу books_urls с видом book_id,book_url,author_url или оставить в большой бд? для доступа к странице с книгой будет использоваться запрос селекса книги, где автор и название тождественны GET реквесту, или же мы запрос поиска делаем по общей таблице с книгами, где можно оставить эти поля?

в большой таблице *

чел, то что тебе требуется часто и первоочередно, то оставляешь. по ней и работаешь. все что идет грузом. выносишь.

да и вывод всей инфы по книге сомнительная затея

если ты на странице книги - делай джойны, выводи все