Hi Dmitry M, Is the API Specification [1] section of the documentation auto-generated from the code?
[1] https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/modules.html On Mon, Jul 30, 2018 at 5:05 PM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > Now we are talking. A much better and more user-friendly API. > > D. > > On Fri, Jul 27, 2018 at 7:19 AM, Dmitry Melnichuk < > dmitry.melnic...@nobitlost.com> wrote: > > > Dmitriy, Igor, Ilya, Sergey! > > > > Thank you for sharing your ideas, concerns and criticism with me. I do > > appreciate it. > > > > I already made some changes in my API, influenced by your feedback. I > also > > plan to add a certain set of features, that will make my UX closer to > what > > you can see from other Ignite clients. > > > > I stopped using `hashcode` in my examples. Integer cache IDs and cache > > names now can be used interchangeably, with primary focus on cache names. > > > > I will add a Cache class as a primary interface for cache operations, so > > that earlier examples: > > > > ``` > > conn = Connection() > > conn.connect('127.0.0.1', 10800) > > > > cache_create(conn, 'my cache') > > > > cache_put(conn, 'my cache', 'my key', 42) > > result = my_cache.get('my key') > > > > cache_destroy(conn, 'my cache') > > conn.close() > > ``` > > > > could be reiterated as: > > > > ``` > > conn = Connection() > > conn.connect('127.0.0.1', 10800) > > > > my_cache = conn.create_cache('my cache') > > > > my_cache.put('my key', 42) > > result = my_cache.get('my key') > > > > my_cache.destroy('my cache') > > conn.close() > > ``` > > > > I will also make `Connection.connect()` accept any iterable (including > > simple list) as a connection parameter. I will provide user with some > basic > > connection generators instead of what is done in my current connection > > failover example. > > > > > > On 07/27/2018 07:41 AM, Dmitriy Setrakyan wrote: > > > >> Dmitriy, > >> > >> I would stop using the word "hashcode" in this context. Hash code has a > >> special meaning in Ignite and is used to determine key-to-node > affinity. I > >> agree that passing "cache_name" is the best option. I have no idea when > >> "cache_name" is not going to be known and do not think we need to > support > >> this case at all. My suggestion is to drop the cache_id use case > >> altogether. > >> > >> Also I am really surprised that we do not have a cache abstraction in > >> python and need to pass cache name and connection into every method. To > be > >> honest, this smells really bad that such a popular modern language like > >> Python forces us to have such a clumsy API. Can you please take a look > at > >> the Redis python clients and see if there is a better way to support > this? > >> > >> https://redis.io/clients#python > >> > >> D. > >> > > >
