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 Wed, 25 Jul 2018 08:52:45 GMT

To be honest, I got a bit lost in such a big email. Can you tell us briefly
- why do we not need the hash code on API in Java and we do need it in


On Wed, Jul 25, 2018 at 3:29 AM, Dmitry Melnichuk <
dmitry.melnichuk@nobitlost.com> wrote:

> Hello, Dmitriy, Igor!
> Dmitriy, as you have noted, most cache API functions are parameterized
> with the hash codes, and the function for creating the hash codes is
> documented. I personally see no harm in using hash codes as it is defined
> by low-level client operations. But it may be better to enforce the use of
> cache names throughout the Python library, or use names and hash codes
> interchangeably where possible.
> Igor, you are right, due to the procedural nature of my client library,
> there is no cache class in it. Caches in Ignite, from Python perspective,
> are one-off, unique, immutable objects. The client code will not benefit
> much from associating any additional context with them. On the contrary,
> handling cache objects in its string or integer representation may
> sometimes be advantageous.
> I guess, the implied question here is: why I chose a procedural approach
> first of all? Well, I am glad to answer it too, although the answer will be
> more verbose.
> Python is often referred as a multi-paradigm programming language, but at
> heart it is a procedural scripting language. It has no obligatory object
> orientation that could influence Java or C# clients' architecture.
> It is also worth noting, that Python has such an elaborate and versatile
> built-in types, so its classes (`object` descendants) is never meant to be
> used as plain data containers. That is unlike JavaScript, where `object` is
> a legitimate default complex data type. Any combination of
> list/set/dict/defaultdict/OrderedDict is always a better, more Pythonic
> choice; getter/setter semantics is considered an anti-pattern.
> Considering the above, the client API architecture could be chosen
> depending on the application field. Aiming for the most versatility,
> however, I decided to implement lower-level procedural API.
> “Lower-level” in this case does not mean extra efforts for the end user.
> Feel free to review the rest of the examples and make sure that those code
> snippets actually take less and do more, comparing to the equivalent code
> using other client APIs.
> If that is still not satisfying, any kind of object-oriented wrapper can
> be built on top of the procedural implementation with little time and
> effort. In fact, before taking the present course of actions, I considered
> the following implementations of other services' clients:
> - key-value libraries, like redis-py, that have their methods incapsulated
> in connection class,
> - RDBMS libraries like psycopg2 with their cursor classes − it could be an
> architectural choice for SQL and scan queries-oriented client,
> - boto3 (Amazon S3 client) have its methods incapsulated in bucket
> objects, somewhat analogous to Ignite caches, but notably different: a) S3
> supports only one data type: file, b) bucket can be reconfigured on the
> fly, unlike Ignite cache,
> - there could be other architectural choices too.
> I will be glad to answer your further questions. If you have suggestions
> about higher-level abstractions and their use cases, please let me know.
> Dmitry
> On 07/24/2018 10:43 PM, Dmitriy Setrakyan wrote:> Yes, looks strange? Why
> is the hash code part of API?
> >
> > On Tue, Jul 24, 2018, 13:38 Igor Sapego <isapego@apache.org> wrote:
> >
> >> Ok, I've quickly looked through API and I have a questions. Here
> >> is the code from the example:
> >>
> >> cache_name = 'my cache'
> >> hash_code = hashcode(cache_name)
> >> cache_create(conn, cache_name)
> >> result = cache_put(conn, hash_code, 'my key', 42)
> >>
> >> I'm not familiar with python, so here is the question. Why there is
> >> no "cache" class, and functions with hash code are used?
> >>
> >> Best Regards,
> >> Igor

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