Provide option to use .push instead of .set

[chixcancode]

It would be nice to use .push so that when data is saved it creates a uniqueidentifier.

[mikelehen]

Can you elaborate on what you'd like to see? This sounds interesting, but I'm not 100% sure what sort of behavior you're looking for.

Would the entire JSON file be stored under a push id? Or somehow the JSON file would be split up into entries (how?) and then each entry is stored with a push id?

[NorthMcCormick]

Not sure how active this is: But I believe chixcancode was referring to uploading arrays. I have a data-set I'm migrating from Parse but I need a way to create new ID's for each item and it would be preferable to have firebase generate them. So if I uploaded an array of objects it would create the node that I've referenced, like it does now, but instead of adding each one with 0-x as the 'id' it would be the generated ID.

I'm currently having to hard code ways to upload that data in my app during development since building a tool would take too long and can't use this :S However, once the data is in, then I'd like to be able to use the ID's that are already there. So an argument --usePush or something would work best...

Not sure if that made any sense haha.

[mikelehen]

Yeah, I guess it would verify that the entire file you're importing is an array (i.e. starts with [ and ends with ]) and then replace all the array indexes with push ids. That might be interesting. And that would work for your situation?

[NorthMcCormick]

I think a flag would be good just to make sure the importer knows what's happening, as well as still check if it's an array.

Just thinking of possible cases where indexes would get messed up, but I exported an 'array' and it was built as an object so if I were to re-import the keys should keep their values. So if there is no way the data could get scrambled then automatically detecting if it is an array would work just fine.

It would be a huge help to anyone that is migrating from Parse specifically haha.

[mikelehen]

Yeah. Putting it behind a flag makes sense.

Out of curiosity, can you elaborate on why this would be useful to people migrating from Parse? I would have assumed that parse objects have an id and you'd want to preserve that id when you import into Firebase...

[NorthMcCormick]

They do have ID's however they're not the same format as the firebase generated keys. I'm kind of an all in or all out person, so my users when they first launch the new app version, it is going to log into their parse account, pull the data, and place it in firebase instead of me doing it.

I feel it's important to use the firebase keys, unless I'm totally bonkers and it has no effect on the data at all? Haha

I thought that they can be sorted by, and have some kind of order, whereas I don't think the parse ones do, they use automatically generated created and updated dates

[mikelehen]

Yeah, the advantages of push IDs are that they're auto-generated for you, they're guaranteed unique, and if you order them lexicographically they'll usually be in roughly chronological order by when you added them (because the push id has a timestamp embedded in it).

But if you have existing data with existing IDs, I'd probably go ahead and re-use those IDs, especially if you have any other data that references those IDs (in which case you'd have to do a bunch of extra migration work to fix all those references if you were to change the IDs).

[NorthMcCormick]

Okay so I'm not entirely crazy haha.

Yeah the way I'm going to have the users migrate I won't need the old ID's anymore. There's actually only one node that will reference the old id, but I have that set up already and it will convert them once the user has loaded it once.

I'm lucky with my data that's almost all per-user, nothing shared.