GitHub user dmelnichuk opened a pull request:
https://github.com/apache/ignite/pull/4278 IGNITE-7782 Thin Client lib: Python (initial implementation) Please review this preliminary version of Ignite binary API client library, written in Python 3. What is done: - all API operations implemented, - code is mostly tested (pytest, ~90% covered), - setuptools integration, 100% PyPI-ready, - documentation provided (Sphinx/autodoc). What is **not** yet done: - complex object datatype support, - authentication and authorization support, - throughly tested SQL operations, - improved data checking and error reporting, - ⦠Tested with Python 3.4 and 3.6, Ignite 2.5. You can merge this pull request into a Git repository by running: $ git pull https://github.com/nobitlost/ignite ignite-7782 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4278.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4278 ---- commit 4b444df0000f62c04b97bc2cdb0676ad52880374 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-03-20T21:12:21Z initial implementation commit d1e8014c80f698028d23e09cafd7ea190ac3e929 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-03-20T21:32:52Z initial implementation commit f79229e233ffa7bff1e7c22f04749924af6d712a Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-03-22T09:39:32Z initial implementation commit 658d60b58840080b664e02815f4ba6aac76e5804 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-03-22T16:52:18Z minor update commit 617cef12ad72791c7e7e67179e1b0c3f7f3ae6bb Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-03-25T13:33:27Z api spec commit d9729585f5a901977e2a2e40e86a2b715fab79fa Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-03-25T21:27:11Z link to api_spec added commit ea847eba62e556fa81cbf9838ffe17af60f464e4 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-03-31T22:07:50Z error types modified commit c2ad53fe625cc3a05155eeef3184215388377770 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-03-31T23:41:56Z client states commit 6d2233864b4d891361d38a7143846570bd6c0ef6 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-01T13:11:27Z object types improvement commit 52fbc5f87143da068596141cb59b17b684fd2c1f Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-02T16:59:52Z complex objects commit cae5a28e7e0d610434debcc140738e2f48d061cf Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-02T20:13:00Z object types improvement commit 3165405d4eae09519dc9b5f40f162eb74a9b3c5d Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-02T21:21:26Z client states commit fdbb8f86b32fe4c038d38620a80921be3038f31f Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-03T08:26:04Z Ignite client states described commit 04b946885db0ea2f6fe56a75e28302641dad5f61 Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-03T09:35:49Z minor update commit f4aaf1c3f23c82ba7974b4c571a9984748e5e82e Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-03T12:47:54Z Update ObjectType.js commit e4c8279f4e83b3ed13383420ab3d1417b090a3fa Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-03T13:46:19Z minor updates + api spec commit ed2e4ee830ca40a28dc31958665f52fab6a0bcdd Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-04T14:34:52Z Update ObjectType.js commit 7e1666eb5df82b622a028c0ea949fa21c79e66c2 Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-04T15:14:00Z Update ObjectType.js commit 7b0270d65b597dc1b0d164e78f07c3a21c37ca67 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-08T17:16:43Z sql queries, key value ops commit fe90f53fd08f77add17fbf06d014f9a9b0a11c65 Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-08T18:31:47Z Update IgniteClient.js commit 04137bf5ec3b7077e194edd0100a01bb43f7933a Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-08T18:37:04Z Update CacheConfiguration.js commit b63ad5980718da1b0c44fa4ca138c6e85e47aef3 Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-08T19:11:11Z Update ObjectType.js commit 756b908c9dc38ae497e4d7d740f836dabed93e48 Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-08T22:41:54Z Update CacheClient.js commit e96ffee17298dd25d26a7029738132478271cf92 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-08T23:23:33Z object array, minor updates commit c050e671f74232c4efc41f51c2018d08b152cbbc Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-09T21:04:35Z Update CacheClient.js commit 25052a4e93d6fcc0b0c4789fdd5a1eb85413b5a2 Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-09T22:43:50Z Update ObjectType.js commit c516b4147c10398d4f34d78a8830dd0fcb5f28f4 Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-10T11:50:13Z Update CacheClient.js commit 0e9924a0df8a1d41718fb929698b8e4416f2efa2 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-10T13:21:16Z cache key value operations tests commit e09ee0e7969bffd6f4cfd11579f6d0ff9b486c99 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-10T13:21:50Z Merge branch 'master' of https://github.com/nobitlost/ignite commit 15d2abce41b4f1c9d4d5fecd44a99a5393177482 Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-10T14:38:57Z Update Query.js ---- --- |
Hello Ignite developers!
I would like to bring to your attention, that the new Apache Ignite binary protocol API client library, written in Python 3, is out for your review and evaluation. This client is in an early stage of development and lacks some features, but I am going to further develop and improve it in the near future with your comments, suggestions, and feedback. The following is a PR message. -------- Forwarded Message -------- Subject: [GitHub] ignite pull request #4278: IGNITE-7782 Thin Client lib: Python (initial impl... Date: Thu, 28 Jun 2018 17:31:27 +0000 (UTC) From: dmelnichuk <[hidden email]> Reply-To: [hidden email], [hidden email] To: [hidden email] GitHub user dmelnichuk opened a pull request: https://github.com/apache/ignite/pull/4278 IGNITE-7782 Thin Client lib: Python (initial implementation) Please review this preliminary version of Ignite binary API client library, written in Python 3. What is done: - all API operations implemented, - code is mostly tested (pytest, ~90% covered), - setuptools integration, 100% PyPI-ready, - documentation provided (Sphinx/autodoc). What is **not** yet done: - complex object datatype support, - authentication and authorization support, - throughly tested SQL operations, - improved data checking and error reporting, - ⦠Tested with Python 3.4 and 3.6, Ignite 2.5. You can merge this pull request into a Git repository by running: $ git pull https://github.com/nobitlost/ignite ignite-7782 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4278.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4278 ---- commit 4b444df0000f62c04b97bc2cdb0676ad52880374 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-03-20T21:12:21Z initial implementation commit d1e8014c80f698028d23e09cafd7ea190ac3e929 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-03-20T21:32:52Z initial implementation commit f79229e233ffa7bff1e7c22f04749924af6d712a Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-03-22T09:39:32Z initial implementation commit 658d60b58840080b664e02815f4ba6aac76e5804 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-03-22T16:52:18Z minor update commit 617cef12ad72791c7e7e67179e1b0c3f7f3ae6bb Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-03-25T13:33:27Z api spec commit d9729585f5a901977e2a2e40e86a2b715fab79fa Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-03-25T21:27:11Z link to api_spec added commit ea847eba62e556fa81cbf9838ffe17af60f464e4 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-03-31T22:07:50Z error types modified commit c2ad53fe625cc3a05155eeef3184215388377770 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-03-31T23:41:56Z client states commit 6d2233864b4d891361d38a7143846570bd6c0ef6 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-01T13:11:27Z object types improvement commit 52fbc5f87143da068596141cb59b17b684fd2c1f Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-02T16:59:52Z complex objects commit cae5a28e7e0d610434debcc140738e2f48d061cf Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-02T20:13:00Z object types improvement commit 3165405d4eae09519dc9b5f40f162eb74a9b3c5d Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-02T21:21:26Z client states commit fdbb8f86b32fe4c038d38620a80921be3038f31f Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-03T08:26:04Z Ignite client states described commit 04b946885db0ea2f6fe56a75e28302641dad5f61 Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-03T09:35:49Z minor update commit f4aaf1c3f23c82ba7974b4c571a9984748e5e82e Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-03T12:47:54Z Update ObjectType.js commit e4c8279f4e83b3ed13383420ab3d1417b090a3fa Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-03T13:46:19Z minor updates + api spec commit ed2e4ee830ca40a28dc31958665f52fab6a0bcdd Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-04T14:34:52Z Update ObjectType.js commit 7e1666eb5df82b622a028c0ea949fa21c79e66c2 Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-04T15:14:00Z Update ObjectType.js commit 7b0270d65b597dc1b0d164e78f07c3a21c37ca67 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-08T17:16:43Z sql queries, key value ops commit fe90f53fd08f77add17fbf06d014f9a9b0a11c65 Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-08T18:31:47Z Update IgniteClient.js commit 04137bf5ec3b7077e194edd0100a01bb43f7933a Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-08T18:37:04Z Update CacheConfiguration.js commit b63ad5980718da1b0c44fa4ca138c6e85e47aef3 Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-08T19:11:11Z Update ObjectType.js commit 756b908c9dc38ae497e4d7d740f836dabed93e48 Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-08T22:41:54Z Update CacheClient.js commit e96ffee17298dd25d26a7029738132478271cf92 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-08T23:23:33Z object array, minor updates commit c050e671f74232c4efc41f51c2018d08b152cbbc Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-09T21:04:35Z Update CacheClient.js commit 25052a4e93d6fcc0b0c4789fdd5a1eb85413b5a2 Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-09T22:43:50Z Update ObjectType.js commit c516b4147c10398d4f34d78a8830dd0fcb5f28f4 Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-10T11:50:13Z Update CacheClient.js commit 0e9924a0df8a1d41718fb929698b8e4416f2efa2 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-10T13:21:16Z cache key value operations tests commit e09ee0e7969bffd6f4cfd11579f6d0ff9b486c99 Author: ekaterina-nbl <ekaterina.vergizova@...> Date: 2018-04-10T13:21:50Z Merge branch 'master' of https://github.com/nobitlost/ignite commit 15d2abce41b4f1c9d4d5fecd44a99a5393177482 Author: alexey-nbl <alexey.kosenchuk@...> Date: 2018-04-10T14:38:57Z Update Query.js ---- --- |
Is there an IEP for it where the community can read about the feature set
that will be supported by the Python client? D. On Thu, Jun 28, 2018 at 11:39 AM, Dmitry Melnichuk < [hidden email]> wrote: > Hello Ignite developers! > > I would like to bring to your attention, that the new Apache Ignite binary > protocol API client library, written in Python 3, is out for your review > and evaluation. > > This client is in an early stage of development and lacks some features, > but I am going to further develop and improve it in the near future with > your comments, suggestions, and feedback. > > The following is a PR message. > > -------- Forwarded Message -------- > Subject: [GitHub] ignite pull request #4278: IGNITE-7782 Thin Client lib: > Python (initial impl... > Date: Thu, 28 Jun 2018 17:31:27 +0000 (UTC) > From: dmelnichuk <[hidden email]> > Reply-To: [hidden email], [hidden email] > To: [hidden email] > > GitHub user dmelnichuk opened a pull request: > > https://github.com/apache/ignite/pull/4278 > > IGNITE-7782 Thin Client lib: Python (initial implementation) > > Please review this preliminary version of Ignite binary API client > library, written in Python 3. > What is done: > - all API operations implemented, > - code is mostly tested (pytest, ~90% covered), > - setuptools integration, 100% PyPI-ready, > - documentation provided (Sphinx/autodoc). > What is **not** yet done: > - complex object datatype support, > - authentication and authorization support, > - throughly tested SQL operations, > - improved data checking and error reporting, > - … > Tested with Python 3.4 and 3.6, Ignite 2.5. > > You can merge this pull request into a Git repository by running: > > $ git pull https://github.com/nobitlost/ignite ignite-7782 > > Alternatively you can review and apply these changes as the patch at: > > https://github.com/apache/ignite/pull/4278.patch > > To close this pull request, make a commit to your master/trunk branch > with (at least) the following in the commit message: > > This closes #4278 > ---- > commit 4b444df0000f62c04b97bc2cdb0676ad52880374 > Author: ekaterina-nbl <ekaterina.vergizova@...> > Date: 2018-03-20T21:12:21Z > > initial implementation > > commit d1e8014c80f698028d23e09cafd7ea190ac3e929 > Author: ekaterina-nbl <ekaterina.vergizova@...> > Date: 2018-03-20T21:32:52Z > > initial implementation > > commit f79229e233ffa7bff1e7c22f04749924af6d712a > Author: ekaterina-nbl <ekaterina.vergizova@...> > Date: 2018-03-22T09:39:32Z > > initial implementation > > commit 658d60b58840080b664e02815f4ba6aac76e5804 > Author: ekaterina-nbl <ekaterina.vergizova@...> > Date: 2018-03-22T16:52:18Z > > minor update > > commit 617cef12ad72791c7e7e67179e1b0c3f7f3ae6bb > Author: ekaterina-nbl <ekaterina.vergizova@...> > Date: 2018-03-25T13:33:27Z > > api spec > > commit d9729585f5a901977e2a2e40e86a2b715fab79fa > Author: alexey-nbl <alexey.kosenchuk@...> > Date: 2018-03-25T21:27:11Z > > link to api_spec added > > commit ea847eba62e556fa81cbf9838ffe17af60f464e4 > Author: ekaterina-nbl <ekaterina.vergizova@...> > Date: 2018-03-31T22:07:50Z > > error types modified > > commit c2ad53fe625cc3a05155eeef3184215388377770 > Author: ekaterina-nbl <ekaterina.vergizova@...> > Date: 2018-03-31T23:41:56Z > > client states > > commit 6d2233864b4d891361d38a7143846570bd6c0ef6 > Author: ekaterina-nbl <ekaterina.vergizova@...> > Date: 2018-04-01T13:11:27Z > > object types improvement > > commit 52fbc5f87143da068596141cb59b17b684fd2c1f > Author: ekaterina-nbl <ekaterina.vergizova@...> > Date: 2018-04-02T16:59:52Z > > complex objects > > commit cae5a28e7e0d610434debcc140738e2f48d061cf > Author: ekaterina-nbl <ekaterina.vergizova@...> > Date: 2018-04-02T20:13:00Z > > object types improvement > > commit 3165405d4eae09519dc9b5f40f162eb74a9b3c5d > Author: ekaterina-nbl <ekaterina.vergizova@...> > Date: 2018-04-02T21:21:26Z > > client states > > commit fdbb8f86b32fe4c038d38620a80921be3038f31f > Author: alexey-nbl <alexey.kosenchuk@...> > Date: 2018-04-03T08:26:04Z > > Ignite client states described > > commit 04b946885db0ea2f6fe56a75e28302641dad5f61 > Author: alexey-nbl <alexey.kosenchuk@...> > Date: 2018-04-03T09:35:49Z > > minor update > > commit f4aaf1c3f23c82ba7974b4c571a9984748e5e82e > Author: alexey-nbl <alexey.kosenchuk@...> > Date: 2018-04-03T12:47:54Z > > Update ObjectType.js > > commit e4c8279f4e83b3ed13383420ab3d1417b090a3fa > Author: ekaterina-nbl <ekaterina.vergizova@...> > Date: 2018-04-03T13:46:19Z > > minor updates + api spec > > commit ed2e4ee830ca40a28dc31958665f52fab6a0bcdd > Author: alexey-nbl <alexey.kosenchuk@...> > Date: 2018-04-04T14:34:52Z > > Update ObjectType.js > > commit 7e1666eb5df82b622a028c0ea949fa21c79e66c2 > Author: alexey-nbl <alexey.kosenchuk@...> > Date: 2018-04-04T15:14:00Z > > Update ObjectType.js > > commit 7b0270d65b597dc1b0d164e78f07c3a21c37ca67 > Author: ekaterina-nbl <ekaterina.vergizova@...> > Date: 2018-04-08T17:16:43Z > > sql queries, key value ops > > commit fe90f53fd08f77add17fbf06d014f9a9b0a11c65 > Author: alexey-nbl <alexey.kosenchuk@...> > Date: 2018-04-08T18:31:47Z > > Update IgniteClient.js > > commit 04137bf5ec3b7077e194edd0100a01bb43f7933a > Author: alexey-nbl <alexey.kosenchuk@...> > Date: 2018-04-08T18:37:04Z > > Update CacheConfiguration.js > > commit b63ad5980718da1b0c44fa4ca138c6e85e47aef3 > Author: alexey-nbl <alexey.kosenchuk@...> > Date: 2018-04-08T19:11:11Z > > Update ObjectType.js > > commit 756b908c9dc38ae497e4d7d740f836dabed93e48 > Author: alexey-nbl <alexey.kosenchuk@...> > Date: 2018-04-08T22:41:54Z > > Update CacheClient.js > > commit e96ffee17298dd25d26a7029738132478271cf92 > Author: ekaterina-nbl <ekaterina.vergizova@...> > Date: 2018-04-08T23:23:33Z > > object array, minor updates > > commit c050e671f74232c4efc41f51c2018d08b152cbbc > Author: alexey-nbl <alexey.kosenchuk@...> > Date: 2018-04-09T21:04:35Z > > Update CacheClient.js > > commit 25052a4e93d6fcc0b0c4789fdd5a1eb85413b5a2 > Author: alexey-nbl <alexey.kosenchuk@...> > Date: 2018-04-09T22:43:50Z > > Update ObjectType.js > > commit c516b4147c10398d4f34d78a8830dd0fcb5f28f4 > Author: alexey-nbl <alexey.kosenchuk@...> > Date: 2018-04-10T11:50:13Z > > Update CacheClient.js > > commit 0e9924a0df8a1d41718fb929698b8e4416f2efa2 > Author: ekaterina-nbl <ekaterina.vergizova@...> > Date: 2018-04-10T13:21:16Z > > cache key value operations tests > > commit e09ee0e7969bffd6f4cfd11579f6d0ff9b486c99 > Author: ekaterina-nbl <ekaterina.vergizova@...> > Date: 2018-04-10T13:21:50Z > > Merge branch 'master' of https://github.com/nobitlost/ignite > > commit 15d2abce41b4f1c9d4d5fecd44a99a5393177482 > Author: alexey-nbl <alexey.kosenchuk@...> > Date: 2018-04-10T14:38:57Z > > Update Query.js > > ---- > > > --- > |
Hi, Dmitry!
I guess there will be no IEP specifically for the client, because it has nothing to do with Ignite enhancing, as what IEP stands for. From Ignite side, the purpose and potential capabilities of the thin client, aka binary API client, is best described by this document: https://apacheignite.readme.io/docs/binary-client-protocol From our side, there is some basic info about our project in the corresponding Jira task: https://issues.apache.org/jira/browse/IGNITE-7782 This info is yet to be extended and adjusted. For more in-depth look at our current work in progress please consult our Sphinx documentation. It is contained in our repo in already prebuilt form, and will be updated frequently: https://github.com/nobitlost/ignite/tree/ignite-7782/modules/platforms/python/docs/generated Regarding the feature set, we strive for the most complete implementation of the protocol. However, some of its features (type IDs, filter objects, binary type registering, and may be more) are specific for Java typing system and thus not relevant for Python language, and will unlikely be implemented. Regards, On 06/29/2018 07:53 AM, Dmitriy Setrakyan wrote: > Is there an IEP for it where the community can read about the feature set > that will be supported by the Python client? > > D. |
Dmitry,
I have mentioned Jira task in my reply earlier today. Sorry, but the task description was a bit messy and less than informative. I just updated it. Please have a look. https://issues.apache.org/jira/browse/IGNITE-7782 Please let me know if this information is supposed to be somewhere in Wiki. I'll post it right away. On 06/29/2018 07:53 AM, Dmitriy Setrakyan wrote: > Is there an IEP for it where the community can read about the feature set > that will be supported by the Python client? > > D. |
By the way, guys,
I can see generated docs under source control. We do not store them this way in Ignite. Instead, we have separate step during release, where we generate them and include in binary distribution. So you should remove documents from Git and provide us with instructions on how to generate docs during release. Best Regards, Igor On Fri, Jun 29, 2018 at 5:01 PM Dmitry Melnichuk < [hidden email]> wrote: > Dmitry, > > I have mentioned Jira task in my reply earlier today. Sorry, but the > task description was a bit messy and less than informative. I just > updated it. Please have a look. > > https://issues.apache.org/jira/browse/IGNITE-7782 > > Please let me know if this information is supposed to be somewhere in > Wiki. I'll post it right away. > > On 06/29/2018 07:53 AM, Dmitriy Setrakyan wrote: > > Is there an IEP for it where the community can read about the feature set > > that will be supported by the Python client? > > > > D. > |
Hi Igor,
I totally agree with the point that auto-generated things does not belong to the source tree. I already made short instructions on how to generate HTML documents with Sphinx in README file. The instructions assume that the user is able to use the common tools (Python, pip, virtualenv) and have them installed. From the beginning of the development we found it inconvenient for those who wish to just read the documents and not fire up the whole development process. That's why I included the prebuilt documents in the repository. Note also, that Python programs, unlike Java ones, do not have the additional build step and always distributed as text. So each user will have to build the documents from the source to read it. To leverage this condition, most of Python package developers use readthedocs.org service (freemium, engine is under MIT license) to publish their documentation online. Unfortunately, the service can not be used by our project because of the directory structure. RTD treats the git root as a home to `docs` directory to build Sphinx docs out of it. In our case it would build anything but the documents we need from upstream git source. This situation can be fixed by developing Python thin client in a separate git repository and including it in upstream as a git sub-module, but I see this solution is too radical. Anyway, I am removing the prebuilt docs from now on, just as you suggested. Hope that potential usability problems might be addressed in the future. On 07/02/2018 09:41 PM, Igor Sapego wrote: > By the way, guys, > > I can see generated docs under source control. We do not store them > this way in Ignite. Instead, we have separate step during release, where > we generate them and include in binary distribution. > > So you should remove documents from Git and provide us with instructions > on how to generate docs during release. > > Best Regards, > Igor > |
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 On Mon, Jul 2, 2018 at 9:01 PM Dmitry Melnichuk < [hidden email]> wrote: > Hi Igor, > > I totally agree with the point that auto-generated things does not > belong to the source tree. > > I already made short instructions on how to generate HTML documents with > Sphinx in README file. The instructions assume that the user is able to > use the common tools (Python, pip, virtualenv) and have them installed. > From the beginning of the development we found it inconvenient for > those who wish to just read the documents and not fire up the whole > development process. That's why I included the prebuilt documents in the > repository. > > Note also, that Python programs, unlike Java ones, do not have the > additional build step and always distributed as text. So each user will > have to build the documents from the source to read it. > > To leverage this condition, most of Python package developers use > readthedocs.org service (freemium, engine is under MIT license) to > publish their documentation online. Unfortunately, the service can not > be used by our project because of the directory structure. RTD treats > the git root as a home to `docs` directory to build Sphinx docs out of > it. In our case it would build anything but the documents we need from > upstream git source. This situation can be fixed by developing Python > thin client in a separate git repository and including it in upstream as > a git sub-module, but I see this solution is too radical. > > Anyway, I am removing the prebuilt docs from now on, just as you > suggested. Hope that potential usability problems might be addressed in > the future. > > On 07/02/2018 09:41 PM, Igor Sapego wrote: > > By the way, guys, > > > > I can see generated docs under source control. We do not store them > > this way in Ignite. Instead, we have separate step during release, where > > we generate them and include in binary distribution. > > > > So you should remove documents from Git and provide us with instructions > > on how to generate docs during release. > > > > Best Regards, > > Igor > > > |
Yes, looks strange? Why is the hash code part of API?
On Tue, Jul 24, 2018, 13:38 Igor Sapego <[hidden email]> 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 > > > On Mon, Jul 2, 2018 at 9:01 PM Dmitry Melnichuk < > [hidden email]> wrote: > > > Hi Igor, > > > > I totally agree with the point that auto-generated things does not > > belong to the source tree. > > > > I already made short instructions on how to generate HTML documents with > > Sphinx in README file. The instructions assume that the user is able to > > use the common tools (Python, pip, virtualenv) and have them installed. > > From the beginning of the development we found it inconvenient for > > those who wish to just read the documents and not fire up the whole > > development process. That's why I included the prebuilt documents in the > > repository. > > > > Note also, that Python programs, unlike Java ones, do not have the > > additional build step and always distributed as text. So each user will > > have to build the documents from the source to read it. > > > > To leverage this condition, most of Python package developers use > > readthedocs.org service (freemium, engine is under MIT license) to > > publish their documentation online. Unfortunately, the service can not > > be used by our project because of the directory structure. RTD treats > > the git root as a home to `docs` directory to build Sphinx docs out of > > it. In our case it would build anything but the documents we need from > > upstream git source. This situation can be fixed by developing Python > > thin client in a separate git repository and including it in upstream as > > a git sub-module, but I see this solution is too radical. > > > > Anyway, I am removing the prebuilt docs from now on, just as you > > suggested. Hope that potential usability problems might be addressed in > > the future. > > > > On 07/02/2018 09:41 PM, Igor Sapego wrote: > > > By the way, guys, > > > > > > I can see generated docs under source control. We do not store them > > > this way in Ignite. Instead, we have separate step during release, > where > > > we generate them and include in binary distribution. > > > > > > So you should remove documents from Git and provide us with > instructions > > > on how to generate docs during release. > > > > > > Best Regards, > > > Igor > > > > > > |
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 <[hidden email]> 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 |
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 < [hidden email]> 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 <[hidden email]> 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 > |
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 <[hidden email]> 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 < > [hidden email]> 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 <[hidden email]> 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 > > > |
Igor,
Thank you for your elaborated response. I think the examples you gave me are valid for statically-typed languages only. At least not for Python. If we add an extra parameter to key-value operation, we just add it to a given API function as a named argument (“keyword argument” or “kwarg”) with a sensible default value, so all the dependent code will run as it did before the change, implicitly using the new default value. The newly written code, in turn, will be able to take an advantage of the new parameter by setting it explicitly. This behavior may be impossible in Java or C++ without some additional abstraction layer for isolating caller-supplied parameters from actually used ones. But for any correctly written Python code such isolation level is only superfluous and misleading. The same thing is with the second example. If we stop using a string or integer values as a cache identifiers and replace them with, say, floats or objects, still no dependent code modification is required, taken that the new cache identifiers remain unique and hashable in Pythonic sense (i. e. it should be easy to test them for non-equality), that is only natural for an identifier. All the existing code will continue to work without hassle. The above said is yet more relevant to the end user code, since my API atm is mostly single-levelled and has very few internal codependencies to maintain. On 07/25/2018 08:00 PM, Igor Sapego wrote: > 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 |
In reply to this post by dsetrakyan
Dmitriy,
The short answer is: Python client uses hash code (or any cache identifier) instead of Java Cache object, since such an abstraction is not necessary in Python. As for why (IMO) Cache object may be needed in Java, but not in Python − the main reason is the difference in typing systems of both languages. On 07/25/2018 06:52 PM, Dmitriy Setrakyan 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. > |
Well, at least name should be changed, IMO, as the API function name
should say what we do, and not how we do it. For example, cache_id() looks better to me than hashcode(). Best Regards, Igor On Wed, Jul 25, 2018 at 6:22 PM Dmitry Melnichuk < [hidden email]> wrote: > Dmitriy, > > The short answer is: Python client uses hash code (or any cache > identifier) instead of Java Cache object, since such an abstraction is > not necessary in Python. > > As for why (IMO) Cache object may be needed in Java, but not in Python − > the main reason is the difference in typing systems of both languages. > > On 07/25/2018 06:52 PM, Dmitriy Setrakyan 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. > > > |
Igor,
That is a very good point. It just did not cross my mind during the implementation of this function, that the cache identifier can be abstract. I will fix that. On 07/26/2018 01:46 AM, Igor Sapego wrote: > Well, at least name should be changed, IMO, as the API function name > should say what we do, and not how we do it. For example, cache_id() > looks better to me than hashcode(). > > Best Regards, > Igor |
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. On Wed, Jul 25, 2018 at 5:08 PM, Dmitry Melnichuk < [hidden email]> wrote: > Igor, > > That is a very good point. It just did not cross my mind during the > implementation of this function, that the cache identifier can be abstract. > I will fix that. > > > On 07/26/2018 01:46 AM, Igor Sapego wrote: > >> Well, at least name should be changed, IMO, as the API function name >> should say what we do, and not how we do it. For example, cache_id() >> looks better to me than hashcode(). >> >> Best Regards, >> Igor >> > |
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 On Wed, Jul 25, 2018 at 12:46 PM, Dmitriy Setrakyan <[hidden email]> 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. > > On Wed, Jul 25, 2018 at 5:08 PM, Dmitry Melnichuk < > [hidden email]> wrote: > > > Igor, > > > > That is a very good point. It just did not cross my mind during the > > implementation of this function, that the cache identifier can be > abstract. > > I will fix that. > > > > > > On 07/26/2018 01:46 AM, Igor Sapego wrote: > > > >> Well, at least name should be changed, IMO, as the API function name > >> should say what we do, and not how we do it. For example, cache_id() > >> looks better to me than hashcode(). > >> > >> Best Regards, > >> Igor > >> > > > |
In reply to this post by dsetrakyan
Also I remember there are no hashcodes for NodeJS clients
On Wed, Jul 25, 2018 at 10:46 PM, Dmitriy Setrakyan <[hidden email]> 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. > > On Wed, Jul 25, 2018 at 5:08 PM, Dmitry Melnichuk < > [hidden email]> wrote: > > > Igor, > > > > That is a very good point. It just did not cross my mind during the > > implementation of this function, that the cache identifier can be > abstract. > > I will fix that. > > > > > > On 07/26/2018 01:46 AM, Igor Sapego wrote: > > > >> Well, at least name should be changed, IMO, as the API function name > >> should say what we do, and not how we do it. For example, cache_id() > >> looks better to me than hashcode(). > >> > >> Best Regards, > >> Igor > >> > > > -- Sergey Kozlov GridGain Systems www.gridgain.com |
In reply to this post by dsetrakyan
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. |
Free forum by Nabble | Edit this page |