Open alexkreidler opened 3 years ago
Note there is also the as_foundationdb_value
method. It might be debatable whether as_foundationdb_value
or as_foundationdb_key
should be chosen.
I suppose it's possible there could be a separate method to use for tuple encoding the object rather than either of these. You could imagine an advanced version of this that lets you fully encode and decode it with a custom type code (using one of the ones reserved for custom types), or just one that lets you return a type that is already tuple encodable.
@jzhou77 Yes, that makes sense, we should use as_foundationdb_key
for the key and as_foundationdb_value
for the value
@sfc-gh-ajbeamon In fact, I did something similar to work around this: I created a method as_tuples() -> tuple
on my classes and then simply wrote subspace[obj.as_tuples()]
. Then I didn't have to pack and unpack myself. I also implemented as_foundationdb_key()
on the class just by calling fdb.tuple.pack(self.as_tuples())
, although I'm realizing now that I didn't use as_foundationdb_key
anywhere else in the code.
I guess based on this I'd propose:
as_tuples
(or some other name) method if it is available and handle it as if it were a direct tuple returnedas_foundationdb_key
or as_foundationdb_value
(depending on the context) is, use those methods and handle it as bytesThe only thing missing is a method that returns a representation as a type that is directly supported by the tuple layer: e.g. a str
or int
or long
. This could be a separate method like as_tuple_type
, or potentially just be another type returned by the one as_tuples
method.
LMK how this sounds.
Is this proposal saying that the new method as_tuple
would returned a packed tuple byte string in any context where as_foundationdb_key
or as_foundationdb_value
could be used?
I think my preference would be that if a user wants this behavior in a key or value context, they would use the existing functions as_foundationdb_*
and return the packed tuple from them, as you did on your class. To get the behavior of treating the type as a packable tuple type, having the separate as_tuple_type
method that returns either just bytes
or any packable type sounds like a good solution.
I'm not sure if there's a use-case that doesn't address, so if there is let me know.
Currently, users can write
However, when trying to use an object with an
as_foundationdb_key
method with the Subspace or Tuple layer, one getsValueError: Unsupported data type
. For example:Full error traceback
``` Traceback (most recent call last): File "./test.py", line 20, inTo improve the consistency and ease of use of the API, I propose
as_foundationdb_key()
methodI'd love any thoughts or feedback. I'm open to writing a PR if it's welcome.
Thanks for the project!