backand platform: что такое жизненный цикл объектов (или действие триггера db)

Question

Из-за отсутствия точной документации по Backand documents. Интересно, что на самом деле происходит у каждого до, во время, после этапов в событиях создания, обновления, удаления объектов триггера.

Что я получаю в backandCallback аргументы: userInput, dbRow, parameters, userProfile?

Что произойдет, если я обновляю каждую из них на каждом этапе?

чем смысл возвращаемого значения функции ..

А что произойдет, если я прекратить выполнение действий с исключением на каждом этапе?

Answer 1

Создать - перед тем
userInput - вы получили все ключи, которые вы посылаете в сообщении данных, которые существуют в схему минус ключах коллекции типа. если вы обновите этот объект, обновление будет частью сохраненных данных dbRow.

dbRow - пустой объект. обновить его не делают

parameters - у вас есть данные, которые вы отправляете в Post Data. в формате JSON, даже если он не является частью схемы. обновлять его не делает никакого эффекта

userProfile - вы получили здесь деталь пользователя входа {username == useremail, role, app == appName, token== usertoken, requset == same as global requset object}

сделать исключения здесь отменить создание и вернуть строку исключения как ответ на Requst от клиента

Create-While

userInput - как указано выше. но обновление объекта не влияет на сохраненный объект

dbRow - так же, как userInput Плюс ключи id. плюс ключи типа коллекции существует со струнным значением имени коллекции сущностей они должны точками (например: владелец: «пользователь»)

parameters - такой же, как и выше

userProfile - такой же, как и выше

исключение здесь отменить создание и вернуть строку исключения как ответ на Requst от клиента

Создать - после

userInput - то же, что и выше.

dbRow - такой же, как и выше

parameters - такой же, как и выше

userProfile - такой же, как и выше

исключением здесь не отменить создание, но строки возврата исключений в ответ на Требование от клиента.

Это хороший момент для кода, который хочет OT быть уверено, что объект уже создан

---

Update - до того

userInput - ключи, которые вы посылаете в сообщении данных, exsist в схеме (include id btw) минус ключи коллекции типов. обновление объекта размышлять над обновленным dbRow

dbRow - оригинальные данные dbRow перед обновлением. обновить объект не имеет никакого эффекта

parameters - все ключи, которые вы отправляете на данных Поста в формате Json

userProfile - такой же, как процесс создания.

исключение здесь отмена обновления. и возвращать строку исключений в ответ на requst от клиента

Update - в течение

userInput - такой же, как указано выше. Манипулирование объект не сделать afftect обновленной dbRow

dbRow - объект схемы обновленных с помощью клавиш UserInput (id ключ не будет событие обновления, если он существует в UserInput)

parameters - такой же, как и выше

userProfile - то же, что и выше.

исключение здесь отмена обновления. и возвращать строку исключений в ответ на requst от клиента

Update - после того, как

userInput - такой же, как указано выше.

dbRow - такой же, как и выше

parameters - такой же, как и выше

userProfile - такой же, как указано выше.

исключение здесь нет отмена обновления.но возвращать строку исключение как ответ на Requst от клиента

---

Delete - перед тем

userInput - пустой объект {}.

dbRow - оригинал строки, как сохраненный

parameters - пустой объект {}.

userProfile - То же, что и событие создания.

исключение здесь отмена удаление. и возвращать строку исключение как ответ на Requst от клиента

Delete - во

userInput - такой же, как указано выше.

dbRow - такой же, как и выше

parameters - такой же, как и выше

userProfile - такой же, как указано выше.

исключение здесь отмена удаление. и возвращать строку исключение как ответ на Requst от клиента

Delete - после

userInput - такой же, как указано выше.

dbRow - такой же, как и выше

parameters - такой же, как и выше

userProfile - такой же, как указано выше.

исключение здесь нет отмена удаление. но возвращать строку исключения в ответ на запрос от клиента