One improvement idea: allowing any key type (any erlang term) for keys, and letting the backend to deal with it if unsupported. For instance, if I want to throttle an API on IP address, machine id and and user id, I might want to store it directly as a key ([{122, 12, 243,109}, "device_382719", "edward03"]) or a hash of it (:erlang.phash2([{122, 12, 243,109}, "device_382719", "edward03"]) which returns an integer).
ETS and Mnesia could store both forms as-is (not sure about the performances when storing the non-hashed key though, guess it depends on the length). As of today, the mandatory conversion to a binary might unnecessarily degrade performance.
Hi,
One improvement idea: allowing any key type (any erlang term) for keys, and letting the backend to deal with it if unsupported. For instance, if I want to throttle an API on IP address, machine id and and user id, I might want to store it directly as a key (
[{122, 12, 243,109}, "device_382719", "edward03"]
) or a hash of it (:erlang.phash2([{122, 12, 243,109}, "device_382719", "edward03"])
which returns an integer).ETS and Mnesia could store both forms as-is (not sure about the performances when storing the non-hashed key though, guess it depends on the length). As of today, the mandatory conversion to a binary might unnecessarily degrade performance.