Что корректный путь состоит в том, чтобы скопировать блобы ZODB?
Ссылка: Google Event Insert V3 с использованием oauth2.0 и учетных записей служб
Для запроса имеются тело запроса и параметры запроса. sendUpdates - это параметр запроса, используемый в теле запроса, поэтому уведомления и приглашения не отправляются.
Используйте приведенный ниже код: удалите атрибут sendUpdates из тела запроса события, если оно есть.
$service = new Google_Service_Calendar($this->client);
$event = $service->events->insert($this->calendar_id, $event, array('sendUpdates' => 'all'));
Тело запроса такое же, как указано выше.
Благодаря.
3 ответа
Резервное копирование "blobstorage" сделает это. Никакая потребность в специальном порядке или чем-либо еще, это очень просто.
Все операции в Plone являются полностью транзакционными, так совершают нападки, резервное копирование посреди транзакции должно работать просто великолепно. Поэтому можно сделать живые резервные копии ZODB. Не зная, какая файловая система Вы идете, я предположил бы, что она должна работать, как предназначено.
Ваша стратегия резервного копирования FileStorage прекрасна. Однако создание резервного копирования любой базы данных, которая хранит данные в нескольких файлах, никогда не легко, поскольку Ваша копия должна произойти без записей с различными файлами. Для FileStorage слепая глупая копия прекрасна, поскольку это - просто единственный файл. (Используя repozo еще лучше.)
В этом случае (с BlobStorage, объединенным с FileStorage), я должен указать на совет регулярного резервного копирования:
- выведите дб из эксплуатации при создании копии файловой системы
- используйте инструменты снимка как LVM для замораживания диска в данной точке
- сделайте транзакционный экспорт (не выполнимый на практике)
Резервное копирование репозитория Data.fs с последующим выполнением rsync каталога blobstorage должно быть безопасным, если база данных не получает упакованы, пока происходят эти две операции.
Это связано с тем, что, по крайней мере, при использовании больших двоичных объектов с FileStorage, модификации большого двоичного объекта всегда приводят к созданию нового файла с именем на основе идентификатора объекта и идентификатора транзакции. Поэтому, если новые или обновленные большие двоичные объекты записываются после резервного копирования Data.fs, это не должно быть проблемой, поскольку файлы, на которые ссылается Data.fs, все еще должны быть рядом. Удаление большого двоичного объекта не приводит к удалению файла до тех пор, пока база данных не будет упакована, так что это тоже нормально.
Выполнение резервного копирования в другом порядке или с упаковкой во время резервного копирования может привести к созданию резервной копии Data.fs, которая ссылается на большие двоичные объекты, не включенные в резервную копию.