Hello! I expect the effect to be neligible, and UX gain is well worth it.
In case it will ever become a sensitive issue, hashcode-based operation might be retained as mentioned earlier. Regards, -- Ilya Kasnacheev 2018-07-26 17:39 GMT+03:00 Igor Sapego <isap...@apache.org>: > Ilya, > > This may affect performance in a negative way, as it requires > additional hashcode calculation on every cache operation. > > Best Regards, > Igor > > > On Thu, Jul 26, 2018 at 5:02 PM Ilya Kasnacheev <ilya.kasnach...@gmail.com > > > wrote: > > > Hello! > > > > I think that having both options is indeed preferable. > > > > Regards, > > > > -- > > Ilya Kasnacheev > > > > 2018-07-26 16:51 GMT+03:00 Dmitry Melnichuk < > > dmitry.melnic...@nobitlost.com> > > : > > > > > Hi, Ilya! > > > > > > I considered this option. Indeed, the code would look cleaner if only > one > > > kind of identifier (preferably the human-readable name) was used. But > > there > > > can be a hypothetical situation, when the user is left with hash code > > only. > > > (For example, obtained from some other API.) It would be sad to have an > > > identifier and not be able to use it. > > > > > > Now I really think about using hash codes and names interchangeably, so > > > both > > > > > > ``` > > > cache_put(conn, 'my-cache', value=1, key='a') > > > ``` > > > > > > and > > > > > > > > > ``` > > > cache_put(conn, my_hash_code, value=1, key='a') > > > ``` > > > > > > will be allowed. > > > > > > This will be a minor complication on my side, and quite reasonable one. > > > > > > > > > On 07/26/2018 10:44 PM, Ilya Kasnacheev wrote: > > > > > >> Hello! > > >> > > >> Why not use cache name as string here, instead of cache_id()? > > >> > > >> cache_put(conn, 'my-cache', value=1, key='a') > > >> > > >> Regards, > > >> > > >> > > >
