[GitHub] ignite pull request #4278: IGNITE-7782 Thin Client lib: Python (initial impl...
Locked
12
12
 
|
Hi Prachi!
At the moment I already have my documents (temporarily) published at RTD. This is how they look like at a whole: https://apache-ignite-binary-protocol-client.readthedocs.io/ I already have a separate section on examples: https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/examples.html My build process is also documented here https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/readme.html#documentation and there https://github.com/nobitlost/ignite/blob/ignite-7782/modules/platforms/python/README.md This instructions works for me, and I have at least one report of successful documentation build from elsewhere. And RTD is using basically the same way to put my docs online. My way of document building is pretty common for Python package developers, but if it needs some modifications to fit into Ignite process, please let me know. All the document sources (both autodoc'ed and hand-crafted) is available at https://github.com/nobitlost/ignite/tree/ignite-7782/modules/platforms/python/docs I will be glad to answer any questions. On 07/26/2018 06:25 AM, Prachi Garg wrote: > Hi Dmitry M, > > I am resposible for managing the Ignite documentation. At some point we > will merge the python documentation on github into the main Ignite > documentation. Currently, I am trying to restructure our thin client > documentation in a way that it (thin client documentation) is consistent > for all supported languages - Java, Node.js, Python etc. > > I looked at the python document on github. Under the :mod:`~pyignite.api` > section, I see all the components - cache config, key value, sql, binary > types - but there are no code snippets. Is it possible for you describe > these components with code examples? > > See for example - > https://apacheignite.readme.io/docs/java-thin-client-api#section-sql-queries > where the SQL Queries section explains, with example, how the thin client > SQL API can be used. > > Similarly, please see - > https://apacheignite.readme.io/docs/java-thin-client-security > https://apacheignite.readme.io/docs/java-thin-client-high-availability > https://apacheignite.readme.io/docs/java-thin-client-api > > Thanks, > -Prachi |
|
|
In reply to this post by Dmitry Melnichuk
Hello!
Why not use cache name as string here, instead of cache_id()? cache_put(conn, 'my-cache', value=1, key='a') Regards, -- Ilya Kasnacheev 2018-07-26 5:11 GMT+03:00 Dmitry Melnichuk <[hidden email]>: > Either > > ``` > conn = Connection('example.com', 10800) > cache_put(conn, cache_id('my-cache'), 'a', 1) > ``` > > or > > ``` > conn = Connection('example.com', 10800) > my_cache_id = cache_id('my-cache') > cache_put(conn, my_cache_id, 'a', 1) > ``` > > It is also possible to give parameters names, if you like to. > > ``` > conn = Connection('example.com', 10800) > cache_put(conn, cache_id('my-cache'), key='a', value=1) > ``` > > This should also work, but not recommended: > > ``` > conn = Connection('example.com', 10800) > cache_put(conn, cache_id('my-cache'), value=1, key='a') > ``` > > All variants can coexist in one user program. > > > On 07/26/2018 05:46 AM, Dmitriy Setrakyan wrote: > >> I am still confused. Let's work through an example. Suppose I have a cache >> named "my_cache" and I want to put an entry with key "a" and value "1". >> >> In Java, this code will look like this: >> >> >> *IgniteCache<...> myCache = ignite.cache("my-cache");myCache.put("a", >>> 1);* >>> >> >> >> How will the same code look in Python? >> >> D. >> > |
|
|
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, > |
|
|
Hello!
I think that having both options is indeed preferable. Regards, -- Ilya Kasnacheev 2018-07-26 16:51 GMT+03:00 Dmitry Melnichuk <[hidden email]> : > 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, >> >> |
|
|
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 <[hidden email]> wrote: > Hello! > > I think that having both options is indeed preferable. > > Regards, > > -- > Ilya Kasnacheev > > 2018-07-26 16:51 GMT+03:00 Dmitry Melnichuk < > [hidden email]> > : > > > 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, > >> > >> > |
|
|
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 <[hidden email]>: > 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 <[hidden email] > > > wrote: > > > Hello! > > > > I think that having both options is indeed preferable. > > > > Regards, > > > > -- > > Ilya Kasnacheev > > > > 2018-07-26 16:51 GMT+03:00 Dmitry Melnichuk < > > [hidden email]> > > : > > > > > 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, > > >> > > >> > > > |
|
|
In reply to this post by Dmitry Melnichuk
Thanks Dmitry. I'll look at the docs.
On Wed, Jul 25, 2018 at 8:11 PM, Dmitry Melnichuk < [hidden email]> wrote: > Hi Prachi! > > At the moment I already have my documents (temporarily) published at RTD. > This is how they look like at a whole: > > https://apache-ignite-binary-protocol-client.readthedocs.io/ > > I already have a separate section on examples: > > https://apache-ignite-binary-protocol-client.readthedocs.io/ > en/latest/examples.html > > My build process is also documented here > > https://apache-ignite-binary-protocol-client.readthedocs.io/ > en/latest/readme.html#documentation > > and there > > https://github.com/nobitlost/ignite/blob/ignite-7782/modules > /platforms/python/README.md > > This instructions works for me, and I have at least one report of > successful documentation build from elsewhere. And RTD is using basically > the same way to put my docs online. > > My way of document building is pretty common for Python package > developers, but if it needs some modifications to fit into Ignite process, > please let me know. > > All the document sources (both autodoc'ed and hand-crafted) is available at > > https://github.com/nobitlost/ignite/tree/ignite-7782/modules > /platforms/python/docs > > I will be glad to answer any questions. > > > On 07/26/2018 06:25 AM, Prachi Garg wrote: > >> Hi Dmitry M, >> >> I am resposible for managing the Ignite documentation. At some point we >> will merge the python documentation on github into the main Ignite >> documentation. Currently, I am trying to restructure our thin client >> documentation in a way that it (thin client documentation) is consistent >> for all supported languages - Java, Node.js, Python etc. >> >> I looked at the python document on github. Under the :mod:`~pyignite.api` >> section, I see all the components - cache config, key value, sql, binary >> types - but there are no code snippets. Is it possible for you describe >> these components with code examples? >> >> See for example - >> https://apacheignite.readme.io/docs/java-thin-client-api#sec >> tion-sql-queries >> where the SQL Queries section explains, with example, how the thin client >> SQL API can be used. >> >> Similarly, please see - >> https://apacheignite.readme.io/docs/java-thin-client-security >> https://apacheignite.readme.io/docs/java-thin-client-high-availability >> https://apacheignite.readme.io/docs/java-thin-client-api >> >> Thanks, >> -Prachi >> > |
|
In reply to this post by Dmitry Melnichuk
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. On Thu, Jul 26, 2018 at 9:51 AM, Dmitry Melnichuk < [hidden email]> wrote: > 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, >> >> |
|
|
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. |
|
|
Now we are talking. A much better and more user-friendly API.
D. On Fri, Jul 27, 2018 at 7:19 AM, Dmitry Melnichuk < [hidden email]> 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. >> > |
|
|
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 <[hidden email]> 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 < > [hidden email]> 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. > >> > > > |
|
|
Hello, Prachi!
The section is a hand-written .rst-file, which contains links to some content, generated from code with `sphinx-apidoc`. All autogenerated content resides in `source` folder. For example, this is an autogenerated page: https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/source/pyignite.client.html And this is written by hand: https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/datatypes/parsers.html On 9/6/18 9:39 AM, Prachi Garg wrote: > 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 > |
|
|
Thanks Dmitry!
On Wed, Sep 5, 2018 at 11:59 PM, Dmitry Melnichuk < [hidden email]> wrote: > Hello, Prachi! > > The section is a hand-written .rst-file, which contains links to some > content, generated from code with `sphinx-apidoc`. > > All autogenerated content resides in `source` folder. For example, this is > an autogenerated page: > > https://apache-ignite-binary-protocol-client.readthedocs.io/ > en/latest/source/pyignite.client.html > > And this is written by hand: > > https://apache-ignite-binary-protocol-client.readthedocs.io/ > en/latest/datatypes/parsers.html > > > On 9/6/18 9:39 AM, Prachi Garg wrote: > >> 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 >> >> |
[GitHub] ignite pull request #4278: IGNITE-7782 Thin Client lib: Python
|
|
In reply to this post by andrey-kuznetsov
|
«
Return to Apache Ignite Developers - Legacy Mail Archive
|
1 view|%1 views
| Free forum by Nabble | Edit this page |