Firebase / timestamp

[srcreigh]

Hey everyone, I've added @moezbhatti to the test app firebase we're working with 1. LMK if you want to be added to it as well --- @sitefeng should probably want to have access to it. Can you send me your email in a reply / on facebook si te?

Kartik's made an awesome issue (see #8) about the format of the data. One thing to make sure to do is to format timestamps as ISO8601 compatible strings. @moezbhatti I'm sure you can google around to see how to generate some of these timestamps for testing---there's also definitely a way to generate them from Java Time. @sitefeng same for iOS / objc.

[srcreigh]

Also just FYI since @moezbhatti and @sitefeng may have not used firebase before:

• you can use the Forge interface at 1 to add / delete data
• be careful with deleting data that you didn't add—it's best to double check here first
• the lists of data are a little confusing:
  • they've been randomly generated using the http REST API that firebase gives for adding data to lists
  • they determine the order of the elements; those random strings are sorted alphabetically
  • if you're adding data to a list by hand and the order matters, use strings like "aaa", "aab", "aac", etc as the keys
  • if the data doesn't need to be sorted, or is sorted by a field of the object (like mentors will be sorted alphabetically), then don't worry about the key. you can use a random key.

LMK if you have any other questions.

[KartikTalwar]

:+1:

[moezbhatti]

Not a huge deal, but shouldn't we be using "date" instead of "time" in the firebase? @sitefeng

[KartikTalwar]

2014-08-06T02:01:19Z would be preferred

[moezbhatti]

I meant as the identifier, not the data Like I said, it's a very very minor issue

So I mean that it would be date:2014-08-06T02:01:19Z instead of time:2014-08-06T02:01:19Z

[KartikTalwar]

yeah.. let's not debate about this yet. technically it should be datetime but feel free to pick whichever

[sitefeng]

Date would be right. And apparently I searched that ISO8601 has the ZZZZZ format(-04:00) at the end instead of Z(-0400). So I did the first. Again, these are easily exchangeable in code, so pick whichever is easier.

[srcreigh]

@sitefeng, I noticed that the data you have in Firebase for mentors, prizes, etc. are indexed by integers (0, 1, 2, etc).

Using 0, 1, 2, etc exclusively as keys in a Firebase tree causes Firebase to create an array. This is not what we want. Firebase doesn't support Arrays very well, in particular the APIs for working with lists of data (i.e. appending to a list, retrieving a list, etc) all use JSON Objects with string keys.

This will become important when I work on the scripts to automate sending out updates, adding mentors and prizes, etc. We can't write our code to expect JSON Arrays, because when we start using the list APIs, Firebase will add string keys and make them JSON Objects.

I know that you've probably already implemented some code with JSON arrays. This sucks, because I don't think we have a choice but to expect JSON objects as arrays with string keys.

I'm going to fix the test data to use String keys. You'll have to reimplement any JSON stuff you have to expect JSON objects with string keys instead of arrays.

One caveat: There are certain things that we won't ever update using an API, such as the array of roles in a team member / volunteer object. We can use arrays for this.

[sitefeng]

@srcreigh If that's easier to implement, then definitely go ahead and make it a JSON object. The rules for whether Firebase gives out an array or object is actually quite clear; if more than half of the keys are continuous parseable strings/int, then it will produce an array.

I would say we should make all the existing arrays into object just in case we do need to change those info as well, and for the sake of the same structure.

[srcreigh]

It's not so much an an issue of what's easier to implement. Adding a thing to a list in Firebase with their API will add a unique String as a key and the value being the thing. We have to write our code to use objects or else we'll have to use the API in an obtuse way.

Really? That doesn't seem correct. I added a single string key with a value to a list that had 2 int keys with values and it produced an object.

And okay, that's fair. That way we won't have to worry about using arrays anywhere in our code, which is nice.