ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Thin Client lib: Python
Date Tue, 31 Jul 2018 00:05:12 GMT
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.melnichuk@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.
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message