Hello, and thank you all for rereleasing FoundationDB as an open source project.
I am reading about and planning to use FoundationDB, with one of the uses being to store data that would be referenced by a key containing an ID returned from a latitude/longitude-based R-tree query, from within a client application.
Is there is a consensus on the appropriate type of key IDs to use for retrieving location-specific data for individual values based on WGS84 coordinates?
I ask because I’ve found conflicting info about the behavior of tuple encoding in the Go library/package, so I am curious about how that will work in the near future.
I don’t believe that my use-case would require key range queries, as any queries would be handled by the client application. Some precision-loss, such as when using a Geohash string with a precision of 12, would be acceptable.
So for example, would it be more space-efficient to use a tuple type
(37.3316812, -122.0301672), or to use a Geohash string
Another, more direct way of phrasing this:
In this case, would the FDB client parse and encode the values contained within the tuples as the bytes representing the individual single/double precision floats, or would it encode the character values as an array of UTF-8 bytes?
To add to this, it says in the Go docs:
- “FoundationDB tuples can currently encode byte and unicode strings, integers and NULL values.”
while under the
TupleElement type it says:
- “The valid types for TupleElement are byte (or fdb.KeyConvertible), string, int64 (or int), float, double, bool, UUID, Tuple, and nil.”
Since posting this, I have looked at the code and it seems that the confusion stemmed from a doc comment that wasn’t updated with the code itself. Tuple encoding does handle floats efficiently, and that was added recently, in 5.0.0.