Dmitriy, To me it seems that procedural approach makes it harder to maintaine code and add new features. For example, imagine that we are adding new feature for a thin client, and now we need to pass one more cache parameter when doing any key-value operation, such as put. In your approach, you will need to rewrite all the Cache API, adding new argument to all the functions.
To give you another example, it is possible, that in future we will change the way cache is identified, so the "hash" argument will become deprecated in your approach. To put it simple, procedural approach lacks encapsulation, which is extremely important when you write library code and want to maintain backward compatibility. It removes the separation between public API, which we should not change from version to version, and private code, which we are free to change whenever and however we want. Best Regards, Igor On Wed, Jul 25, 2018 at 11:53 AM Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > Dmitriy, > > 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 > Python? > > D. > > On Wed, Jul 25, 2018 at 3:29 AM, Dmitry Melnichuk < > dmitry.melnic...@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 <isap...@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 > > >
