geofire-java icon indicating copy to clipboard operation
geofire-java copied to clipboard

Update location without remove data

Open inromualdo opened this issue 6 years ago • 12 comments

I have this:

"_id": {
   l: [],
   g: "ede45",
   username: "romuald",
   other: 5
}

If i call setLocation to update location, it will remove username and other.

inromualdo avatar Mar 30 '18 10:03 inromualdo

@inromualdo thanks for the suggestion.

It does seem like here: https://github.com/firebase/geofire-java/blob/master/common/src/main/java/com/firebase/geofire/GeoFire.java#L174-L182

We use setValue but we could use updateChildren.

@vanniktech am I being dumb? Is there a reason why updateChildren would not be appropriate here?

samtstern avatar Mar 30 '18 18:03 samtstern

Good question. Honestly I have no idea since I've never used Geofire for writing.

vanniktech avatar Mar 30 '18 19:03 vanniktech

Can we add updateLocation method?

inromualdo avatar Mar 30 '18 23:03 inromualdo

There is no way to store additional information about objects in the same location as the geohashes. If you need to store additional information, store it in a separate node with the same key as you use in Geofire.

puf avatar Mar 31 '18 14:03 puf

But why this listener GeoQueryDataEventListener? I store additional information in the same location as the geohashes and every thing work well. Now, i need to update the geohashes.

inromualdo avatar Mar 31 '18 19:03 inromualdo

It says that the new API is read only.

vanniktech avatar Mar 31 '18 19:03 vanniktech

In the Read me:

https://github.com/firebase/geofire-java#data-events

If you are storing model data and geo data in the same database location, you may want access to the DataSnapshot as part of geo events. In this case, use a GeoQueryDataEventListener rather than a key listener. what does this mean?

m7mdyahia avatar May 06 '18 14:05 m7mdyahia

@m7mdyahia traditionally GeoFire stores the geo information at a separate location from the actual data. Some users override this and store the geo information and the data together. In these cases they can use the other kind of listener to get a full DataSnapshot for geo queries rather than just a String for the key.

samtstern avatar May 07 '18 16:05 samtstern

@samtstern Is @jwiesmann 's pull request going to be merged anytime soon? It was submitted by jwiesmann on the 1st of Sept. Swift/Obj-C and JS are getting updated regularly though.

mcg95 avatar May 02 '19 06:05 mcg95

@mcg95 I would like to merge that PR but we basically have a big, fundamental problem in geofire-java right now. The library was built to serve Java Server and Android Java users at the same time. It relied on a coincidence: the Android and Java SDKs for Firebase RTDB had all the same signatures.

This is no longer true. The Android and Java Admin SDKs have diverged (for good reasons) so this can no longer be one library.

Before we can really make any more improvements, we have to split the whole library up into geofire-java and geofire-android. I have not had time to do this yet.

samtstern avatar May 02 '19 16:05 samtstern

@samtstern Oh okay. Is there any approximate ETA for the release of this? Maybe 1 or 2 months?

mcg95 avatar May 09 '19 08:05 mcg95

This is the solution I adopted for this : You can generate the geHash from your code and set the value from the node directly in the firebase. GeoHash geoHash = new GeoHash(location); ref.child("g").setValue(geoHash.getGeoHashString()); ref.child("l").setValue(Arrays.asList(location.latitude, location.longitude));

NONOLGG avatar Jun 13 '20 23:06 NONOLGG