Why I can't add records like {foo:{}} ?

Skip to first unread message

Michal Till

Sep 30, 2013, 2:15:03 AM9/30/13
to fireba...@googlegroups.com

when I tred to add document {foo:{}} to path a.b.c I expected it to create a ...c.foo children with an empty set. 

Suppose i have a path firebase.documents where I want to add documents based on some specific ID, like firebase.documents.somedocument . So here somedocument will be an empty hash.

It seems kinda logical this way based on how JSON works. 


Michael "Kato" Wulf

Sep 30, 2013, 12:35:37 PM9/30/13
to fireba...@googlegroups.com
Hello Michal!

Since Firebase is essentially a schema-less JSON structure, which is an important part of dynamic real-time data, there is no way to store an empty object/array/null value. You can use a falsy value like 0 or false to force it to exist I recall a couple posts on StackOverflow about this particular question, so I'll direct you there for more details:

Michael "Kato" Wulf 

You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Michal Till

Oct 1, 2013, 12:46:29 AM10/1/13
to fireba...@googlegroups.com
>Since Firebase is essentially a schema-less JSON structure, [...] there is no way to store an empty object/array/null value.

Honestly... how are these things related? The former IMHO does not imply the latter.

Creating an empty "record" and later testing for its existence seems pretty obvious scenario to me... 


Michael Lehenbauer

Oct 1, 2013, 11:30:25 AM10/1/13
to fireba...@googlegroups.com
Hey guys, since this is where all the Michaels are hanging out, I thought I'd chime in. :-)

The basic reason we behave this way is because of our hierarchical (tree) structure.  We don't have a notion of records.  We just have one big tree of data that you can modify at will.  In a plain record store it might make sense to create a "mike" record in the "users" table and later test for its existence or delete it.  But in Firebase, you can write to /users/ or /users/mike or /users/mike/name or /users/mike/name/first, and these are all fundamentally the exact same operation (updating an arbitrary location in the tree with new data).

So what should happen if you write to /users/mike/name but you didn't first "create" /users or /users/mike ?  Our answer is that these intermediary locations automatically come into existence.  Similarly, if you write to /users/mike/name and then remove it, what should happen to /users/mike now?  Rather than it being an "empty" record that you have to delete (even though you never explicitly created it), it just goes out of existence, as if you never created anything there in the first place.

Admittedly this model is a little different and takes getting used to, but we find it works quite well (is more convenient and reduces a lot of error conditions).  It does mean you need to use a value other than null or { } if you want an "empty" placeholder though.

Hopefully my explanation at least helps understand how we arrived here.

Best regards,
-One of the Michaels

Reply all
Reply to author
0 new messages