firebase / geofire-objc

GeoFire for Objective-C - Realtime location queries with Firebase
MIT License
436 stars 180 forks source link

Update location with updateChildValues #108

Closed RaMin0 closed 6 years ago

RaMin0 commented 6 years ago

Use updateChildValues (and setPriority) in favor of setValuesAndPriority to avoid overwriting other child values.

googlebot commented 6 years ago

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

:memo: Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.


What to do if you already signed the CLA

Individual signers
Corporate signers
googlebot commented 6 years ago

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

:memo: Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.


What to do if you already signed the CLA

Individual signers
Corporate signers
RaMin0 commented 6 years ago

I signed it!

googlebot commented 6 years ago

CLAs look good, thanks!

morganchen12 commented 6 years ago

@mcdonamp please review

asciimike commented 6 years ago

@RaMin0 @morganchen12 it looks like we don't actually need priority (we store the geohash in g and query by that, rather than priority), so I'd just remove the code and tests for priority and use update, no need to do the second update.

Presumably this is so you can store additional data alongside the GeoFire info?

RaMin0 commented 6 years ago

@mcdonamp: Presumably this is so you can store additional data alongside the GeoFire info

Yes, it made more sense to save the related info stored in the same node rather than having a parallel node that I have to maintain just to keep the extra info.

One other thing I suggest to do is to make the name of the location key (currently l) configurable, to give more context. pickUpLocation is more significant than just l. But that's an issue for another PR.

RaMin0 commented 6 years ago

@mcdonamp Check 96f40431d0d0fe3aac66bc0302da6c9cf3ab2f58.