Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
SypexDumper №1. Как-то делал интеграцию для одного cmf — cogear. Очень просто и удобно.
Посмотрел код — он ужасен. В конструкторе дефайнятся константы — то есть подключится к двум БД, что бы сделать дамп не получится. Какой тогда смысл в этом объекте? Нет разделения на MVC: в index.php сложено сразу и классы и вёрстка.
Пожелание.
Разделить на два уровня: библиотека классов + html-интерфейс, что бы я мог выкинуть интерфейсную часть и подключить только классы инклюдом. Тогда я смогу оставить свой интерфейс админки и просто обращаться к классам примерно так:
А вообще тема актуальная. Хочу в свой велосипед встроить нормальный дампер/импортер что бы не изобретать велик.
Пожелание.
Разделить на два уровня: библиотека классов + html-интерфейс, что бы я мог выкинуть интерфейсную часть и подключить только классы инклюдом. Тогда я смогу оставить свой интерфейс админки и просто обращаться к классам примерно так:
$dumper = new SXDumper($host, $user, $pass, $db);
$dumper->needStructure = true;
$dumper->needData = false;
$dumper->dump($file, $_GET['step']);
// Без гемороя с обходом чужой авторизации и встроено в интерфейсе моей админки.
А вообще тема актуальная. Хочу в свой велосипед встроить нормальный дампер/импортер что бы не изобретать велик.
Вот вам и классический пример: код «ужасен», но работает очень быстро!
Классическое заблуждение. Подумайте, если не использовать глобальные константы и разложить на 3 файла: classes + controller + tpl — разве он станет работать медленнее???
Не знаю. Но я пробовал другие веб дамперы и с классами и MVC — работают медленнее. Да и потом, меня вполне устраивает этот код по функционалу и скорости, вне зависимости от его красоты
Не знаю.
1. Плохо, что вы не знаете, но утверждаете.
2. Этот дампер использует классы так же как и другие тормозящие дамперы.
3. Тормознутость, практически, не зависит от красоты кода.
Ну это не совсем так, если дампер раскидать на сотни мелких классов, как сейчас любят, то тормозить будет прилично. Поэтому в дампере классов минимум. Ну а то что всё в одном файле, это скорее наследие первого дампера.
если дампер раскидать на сотни мелких классов
Не надо перевирать мои слова. Я предложил всего лишь 3 файла:
разложить на 3 файла: classes + controller + tpl
Я и не говорил, что это вы сказали. Я сказал «как сейчас модно». В MVC обычно 3-мя файлами не ограничиваются, в таких случаях.
У дампера критична не скорость его первоначальной загрузки, а максимальный размер базы данных которую он дампит. К слову Sypex Dumper с этим справляется на ура. То что код ужасен не критично. Но как только появится достойный конкурент с превосходным кодом я сразу на него перейду. Хотя бы потому что его можно будет проще и глубже интегрировать в систему.
Уже предлагал тут, вот что ответил zapimir:
Планируется, но не в ближайшее время. Вся сложность в том, что дампер может работать в несколько этапов, т.е. работа выполняется за несколько запусков скрипта.
Да-да-да. Знакомая проблема. И я это предусмотрел в предлагаемом интерфейсе. Смотрите что я написал выше:
$dumper->dump($file, $_GET['step']);
А вообще обязательно делать работу за несколько запусков скрипта? Похоже на какой-то ужасный костыль.
Обязательно. Если база большая и будет дампиться/импортиться больше 5 минут, то надо разбивать на шаги по нескольким причинам:
1. max_execution_time можно обойти, но ограничение nginx обойти не получится и будет «504 bad gataway»
2. Что бы показывать пользователю процесс. Что бы он видел как бегут проценты. В противном случае, всё может залипнуть на пару часов и пользователь будет в недоумении: а процесс идёт или соединение с сервром отвалилось пол часа наад? А сколько ещё времени осталось: 2 минуты или 2 суток?
3. Что бы пользователь, увидев надпись «осталось 48 часов», мог нажать на кнопку «стоп».
Так что это необходимость, а не костыль.
1. max_execution_time можно обойти, но ограничение nginx обойти не получится и будет «504 bad gataway»
2. Что бы показывать пользователю процесс. Что бы он видел как бегут проценты. В противном случае, всё может залипнуть на пару часов и пользователь будет в недоумении: а процесс идёт или соединение с сервром отвалилось пол часа наад? А сколько ещё времени осталось: 2 минуты или 2 суток?
3. Что бы пользователь, увидев надпись «осталось 48 часов», мог нажать на кнопку «стоп».
Так что это необходимость, а не костыль.
max_execution_time можно обойти, но ограничение nginx обойти не получится и будет «504 bad gataway»
Вы правы лишь отчасти. Обойти можно, используя увеличенный proxy_read_timeout и proxy_send_timeout для локейшена с админкой. Другое дело, что далеко не у всех есть доступ к конфигам nginx'a. Нужно еще угадать со значением таймаута.
Вы правы лишь отчасти. Обойти можно, используя увеличенный proxy_read_timeout и proxy_send_timeout для локейшена с админкой. Другое дело, что далеко не у всех есть доступ к конфигам nginx'a. Нужно еще угадать со значением таймаута.
А с прогрессом задачи как быть и рестартом, будете тоже сами контролировать и выводить?
Ок, вот вы допустим встроили дампер в свою админку, что вы будете делать если база навернулась, её нужно восстановить из бэкапа? В админку вы зайти не можете, т.к. база навернулась. Ну или нужно перенести на другой хостинг, в дампере просто вбиваете логин и пароль от MySQL и разворачиваете базу на новом месте.
Возможно имеет смысл выпустить какой-то отдельный класс для встраивания, но врятли сам дампер будет встраиваемый через include.
Возможно имеет смысл выпустить какой-то отдельный класс для встраивания, но врятли сам дампер будет встраиваемый через include.
Если админка не работает, то программист сможет разобраться. В моей админке система бекапов разработана для домохозяек, что бы секретарша могла сделать бекап, переколбасить контент и поняв что она всё сломала, восстановить обратно. Для этого в админке мне нужно всего 3 вещи:
1. Кнопка «создать бекап» (без каких либо опций)
2. Список созданных бекапов
3. Кнопка «восстановить»
Я не хочу встраивать в админку космический корабль с кучей функций, потому что все программисты используют phpMyAdmin, а секретарша в нём не разберётся.
1. Кнопка «создать бекап» (без каких либо опций)
2. Список созданных бекапов
3. Кнопка «восстановить»
Я не хочу встраивать в админку космический корабль с кучей функций, потому что все программисты используют phpMyAdmin, а секретарша в нём не разберётся.
Т.е. вы рассматриваете бэкап только как средство отката изменений? В целом на эту тему тоже задумывался, что нужен еще какой-то упрощенный интерфейс. Пока что, остановился на следующей мысли.
Сейчас в разработке еще один продукт, под рабочим названием Sypex Backuper, он будет бэкапить всё, и файлы и базу (для БД у него будет функционал дампера). Как раз склоняюсь к тому, чтобы в нем был режим для блондинок. Там можно будет создавать профили бэкапа, т.е. достаточно юзеру выбрать профиль для нужной CMS и бэкап будет делаться по нему (с минимальными настройками, типа галочки бэкапить кэш или нет). Вот как раз там и сделать режим трёх кнопок.
Сейчас в разработке еще один продукт, под рабочим названием Sypex Backuper, он будет бэкапить всё, и файлы и базу (для БД у него будет функционал дампера). Как раз склоняюсь к тому, чтобы в нем был режим для блондинок. Там можно будет создавать профили бэкапа, т.е. достаточно юзеру выбрать профиль для нужной CMS и бэкап будет делаться по нему (с минимальными настройками, типа галочки бэкапить кэш или нет). Вот как раз там и сделать режим трёх кнопок.
делал такое, было сложное решение, но внешне — выглядело также просто… полностью поддерживаю.
Я так еще лет 5 назад делал, еще с предыдущим дампером, думая, что жутко костылю и должно быть как-то проще и нативнее, через API или еще как-то. А оказывается это «официально» рекомендованная практика…
Использовал эту штуку ещё году в 2005-2006 на своём PHP-бложике.
То, что весь код в одном файле не должно беспокоить. Ведь это закрытый «коробочный» продукт, работает быстро и просто. Зачем в код лезть? Это же не опенсорс вроде.
То, что весь код в одном файле не должно беспокоить. Ведь это закрытый «коробочный» продукт, работает быстро и просто. Зачем в код лезть? Это же не опенсорс вроде.
Интересно насколько реально прикрутить SXD в качестве движка к drupal.org/project/backup_migrate для бэкапа/рестора базы и файлов.
Думаю, что почти не реально. SXD реализован как отдельное приложение, которое можно только 1) открывать отдельно, 2) встроить через фрейм и 3) запускать cron'ом. Т.е. никакого API у него нет и наверное не будет, из-за проблем, описанных в комментариях к этому посту.
У Друпала для этого предусмотрен Batch API т.к. тоже есть много задач, выполняемых в несколько присестов, плюс свой крон который может работать посредством системного или в отрыве от него. В общем, думаю можно прикрутить, если озадачиться.
А зачем его встраивать именно в backup and migrate?
Нет. Там заложен только бэкап юзерспейса, т.е. файлы, генерируемые движком и пользователями плюс база. В случае если нужно забэкапить/откатить сайт целиком — лучше внешние средства.
Бекап/рестор не затрагивает сам движок, оно делается на случай если что-то напорят пользователи или повредится база. Повреждения файлов движка маловероятны и бэкапятся ручками (или внешними средствами) при установке апдейтов.
т.е. обычный юзкейс — это Backup migrate каждый день бэкапит базу и файло юзерспейса, а раз в несколько недель делается полный бэкап при помощи SXD+FTP (грубо говоря).
Так вот если-бы была возможность заюзать функционал нового бэкапера с дедупликацией — это было бы мегакруто т.к. это основной объём и для тех, кто живёт на шареде — спасение. Просто тут ещё в чём плюшка: Backup migrate умеет посылать бэкапы почтой / выкладывать на внешний FTP.
В общем — собаководу на заметку, если будет желание прикрутить — оно реально пригодится.
Бекап/рестор не затрагивает сам движок, оно делается на случай если что-то напорят пользователи или повредится база. Повреждения файлов движка маловероятны и бэкапятся ручками (или внешними средствами) при установке апдейтов.
т.е. обычный юзкейс — это Backup migrate каждый день бэкапит базу и файло юзерспейса, а раз в несколько недель делается полный бэкап при помощи SXD+FTP (грубо говоря).
Так вот если-бы была возможность заюзать функционал нового бэкапера с дедупликацией — это было бы мегакруто т.к. это основной объём и для тех, кто живёт на шареде — спасение. Просто тут ещё в чём плюшка: Backup migrate умеет посылать бэкапы почтой / выкладывать на внешний FTP.
В общем — собаководу на заметку, если будет желание прикрутить — оно реально пригодится.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Встраиваем Sypex Dumper в свою админку