Firebase, мульти обновления местоположения

Question

Рассмотрим следующий код для атомных записи на нескольких местах в FireBase:

var ref = new Firebase("https://<YOUR-FIREBASE-APP>.firebaseio.com"); 

var newPostRef = ref.child("posts").push(); 
var newPostKey = newPostRef.key(); 

var updatedUserData = {}; 
updatedUserData["users/"+authData.uid+"/posts/" + newPostKey] = true; 
updatedUserData["posts/" + newPostKey] = { 
    title: "New Post", 
    content: "Here is my new post!" 
}; 

ref.update(updatedUserData, function(error) { 
    if (error) { 
    console.log("Error updating data:", error); 
    } 
}); 

Этот подход может быть использован для обновления пост в разных местах, но как обеспечить атомное обновление на серверная сторона? (по правилам).

Как я могу убедиться, что пользователи не могут обновить местоположение /posts/ (через его прямую ссылку) без заполнения users/UID/posts/ или наоборот?

Answer 1

Существует много возможных таких «бизнес-правил», поэтому я подберу их и реализую. Предположим, что любая публикация, на которую ссылается пользователь, должна существовать. Поэтому вы можете написать только /users/myuid/posts/mypostid, если существует /posts/mypostid. Я также буду выполнять основную проверку самих сообщений.

{ 
    "posts": { 
    "$postid": { 
     ".validate": "hasChildren(['title', 'content'])", 
     "title": { 
     ".validate": "newData.isString()" 
     }, 
     "content": { 
     ".validate": "newData.isString()" 
     }, 
     "$other": { 
     ".validate": false 
     } 
    } 
    }, 
    "users": { 
    "$uid": { 
     "posts": { 
     "$postid": { 
      ".validate": "newData.parent().parent().parent().parent().child('posts').child($postid).exists() 
     } 
     } 
    } 
    } 
} 

Самый большой трюк здесь является newData.parent().parent()... бит, который гарантирует, что мы получаем сообщения в новых данных.

У вас есть привычка задавать такие вопросы, как «как я могу гарантировать, что метод ABC использовался для обновления данных?», Что редко является правильным способом думать о вещах. В приведенных выше правилах я сосредотачиваюсь на проверке структуры данных и действительно не заботятся о том, какие вызовы API могут привести к этим данным.