нет, Моисей здесь не причем, я руководствуюсь общепринятыми практиками и здравым смыслом
полагаю, что под картинками имеете ввиду аватары пользователей, или какие то другие пользовательские картинки (в противном случае не вижу смысла дискутировать дальше, т.к. в предыдущем комменте говорил именно о пользовательских данных)
как же они попадают в репозиторий? у вас на продакшн сервере при каждой загрузке на сайт этих самих картинок, делается коммит и затем периодически это все пушится на удаленный репозиторий?
должен признать, это довольно интересный способ бэкапа, хоть и извращенный. как минимум этот способ не всем подойдет, хотя бы с точки зрения экономии места на дисках (как писали выше).
в статье идет речь о резервном копировании веб-проектов. я вообще не понимаю, причем здесь git?
то что должно храниться в git (исходники) в бэкап по-хорошему можно и не включать, так что это совершенно разные задачи.
да и вообще, как вы предлагаете использовать git для бэкапов продакшн версии сайта со всеми пользовательскими данными и БД?
В кратком справочнике не совсем корректно написано про Defer
Спецификация говорит: Скачивай вместе, выполняй по порядку до DOMContentLoaded. Игнорируй «defer» для скриптов без «src».
Можно подумать, что скрипты могут выполниться до того как загрузится DOM. Мне кажется, лучше не «до DOMContentLoaded», а «прямо перед вызовом события DOMContentLoaded».
А статья замечательная, спасибо за перевод.
<?php
// Подключаем модель models/books.php
loadModel('books');
// Проверяем, пришли ли данные методом POST
<?php
// Подключаем модель models/books.php
loadModel('books');
// Проверяем, пришли ли данные методом POST
Спасибо за критику, статья и вправду получилась немного сумбурной (мало опыта в написании статей). Но все же я не ставил своей целью описывать разные типы долгих задач и методы их решения. Я лишь хотел написать о факторах, которые могут помешать работе таких скриптов.
По поводу того, что не надо решать такие задачи на PHP, не соглашусь. Если у вас уже есть веб-приложение, написанное на PHP, со своими классами и библиотеками, и в нем вам нужно добавить, например, функцию импорта, в которой будут использоваться эти классы и библиотеки, то я не вижу смысла реализовывать ее на другом языке.
поясните, пожалста, что вы имеете ввиду?
в PHP параметр mysqli.reconnect по умолчанию отключен, а следовательно при потере соединения с MySQL оно не будет «прозрачно» восстановлено
по поводу блокировки тоже не понятно
Потрудитесь объяснить причем тут вообще send_timeout.
Таймаут устанавливается не на всю передачу ответа, а только между двумя операциями записями. Если по истечении этого времени клиент ничего не примет, соединение будет закрыто.
На сколько я понимаю, если скрипт отправит что-то клиенту, после чего долгое время (больше чем указано в send_timeout) будет «молчать», то соединение закроется. Поправьте если я ошибаюсь
Это, мягко говоря, не всегда так.
Ну как я и написал за это в PHP отвечает параметр ignore_user_abort. Если вам есть что добавить, то я готов это добавить в статью.
Я вел речь о запланированно долгих скриптах, а не о плохооптимизированных
Долгие операции нужно выносить за пределы, и выполнять их, например, в кроне.
вообще-то, в конце я написал о том, что долгие операции следует выполнять в фоновом режиме (в кроне это делать или запускать в качестве фонового процесса — зависит от задачи и особого значения не имеет)
полагаю, что под картинками имеете ввиду аватары пользователей, или какие то другие пользовательские картинки (в противном случае не вижу смысла дискутировать дальше, т.к. в предыдущем комменте говорил именно о пользовательских данных)
как же они попадают в репозиторий? у вас на продакшн сервере при каждой загрузке на сайт этих самих картинок, делается коммит и затем периодически это все пушится на удаленный репозиторий?
должен признать, это довольно интересный способ бэкапа, хоть и извращенный. как минимум этот способ не всем подойдет, хотя бы с точки зрения экономии места на дисках (как писали выше).
а с БД вы как поступаете? и ее в git?
то что должно храниться в git (исходники) в бэкап по-хорошему можно и не включать, так что это совершенно разные задачи.
да и вообще, как вы предлагаете использовать git для бэкапов продакшн версии сайта со всеми пользовательскими данными и БД?
Можно подумать, что скрипты могут выполниться до того как загрузится DOM. Мне кажется, лучше не «до DOMContentLoaded», а «прямо перед вызовом события DOMContentLoaded».
А статья замечательная, спасибо за перевод.
Не сразу понял откуда "@" в самой первой ячейке. Тоже довольно изящное решение, хоть и мелочь )
а вообще, хорошо бы ссылку на демо
По поводу того, что не надо решать такие задачи на PHP, не соглашусь. Если у вас уже есть веб-приложение, написанное на PHP, со своими классами и библиотеками, и в нем вам нужно добавить, например, функцию импорта, в которой будут использоваться эти классы и библиотеки, то я не вижу смысла реализовывать ее на другом языке.
в PHP параметр mysqli.reconnect по умолчанию отключен, а следовательно при потере соединения с MySQL оно не будет «прозрачно» восстановлено
по поводу блокировки тоже не понятно
согласен, в первую очередь стоит попробовать увеличить таймаут соединения
внес поправку в статью
На сколько я понимаю, если скрипт отправит что-то клиенту, после чего долгое время (больше чем указано в send_timeout) будет «молчать», то соединение закроется. Поправьте если я ошибаюсь
Ну как я и написал за это в PHP отвечает параметр ignore_user_abort. Если вам есть что добавить, то я готов это добавить в статью.
вообще-то, в конце я написал о том, что долгие операции следует выполнять в фоновом режиме (в кроне это делать или запускать в качестве фонового процесса — зависит от задачи и особого значения не имеет)