The database structure for a Firebase "GeoFire" node must look like this (source)
"items" : {
<itemId> : {
"someData" : "someData",
...
}
},
"items_location" : {
<itemId> : {
<geofireData> ...
}
}
But one limitation of Geofire is that only single points can be stored and queried, and no objects like polygons. That's easy to work around - my code can query nearby points, and then reassemble the simple rectangles based on having the same key.
But in splitting my rectangles into individual points, I've created a GeoFire key with the following format
ABCD_0
Where ABCD
is the original Primary Key of the rectangle, and _0
indicates which corner, so as to have each point with a unique key. One rectangle is represented in GeoFire as
"items" : {
<ABCD_0> : {<objectData>},
<ABCD_1> : {<objectData>},
<ABCD_2> : {<objectData>},
<ABCD_3> : {<objectData>}
},
"items_location" : {
<ABCD_0> : {<geofireData 0>},
<ABCD_1> : {<geofireData 1>},
<ABCD_2> : {<geofireData 2>},
<ABCD_3> : {<geofireData 3>}
}
But then to force identical keys in items
and items_location
, <objectData>
is 4x redundant.
In order to decrease data volume, I'd like to use the original Primary Key in the items
node, and then replicate the key with the _X
structure for the items_location
node. The App would then query GeoFire, get a list of (4) nearby keys, and then string-parse ABCD_X
into ABCD
, which it would use for the subsequent query.
"items" : {
<ABCD> : {<objectData>},
},
"items_location" : {
<ABCD_0> : {<geofireData 0>},
<ABCD_1> : {<geofireData 1>},
<ABCD_2> : {<geofireData 2>},
<ABCD_3> : {<geofireData 3>}
}
Will this break how GeoFire stores, indexes, retrieves and offlines data?
I'm especially concerned about how small sets of data is synchronized offline for individual apps. The entire geo-dataset is too large for a single app to store in its entirety offline.
item
anditem_location
, which I thought might negatively affect offline storage – Tiernan