[GitHub] ignite pull request #4278: IGNITE-7782 Thin Client lib: Python (initial impl...

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[GitHub] ignite pull request #4278: IGNITE-7782 Thin Client lib: Python (initial impl...

andrey-kuznetsov
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

----


---
Reply | Threaded
Open this post in threaded view
|

Thin Client lib: Python

Dmitry Melnichuk
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

----


---
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

dsetrakyan
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
>
> ----
>
>
> ---
>
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

Dmitry Melnichuk
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.
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

Dmitry Melnichuk
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.
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

Igor Sapego-2
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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

Dmitry Melnichuk
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
>
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

Igor Sapego-2
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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

dsetrakyan
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
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

Dmitry Melnichuk
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
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

dsetrakyan
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
>
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

Igor Sapego-2
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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

Dmitry Melnichuk
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
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

Dmitry Melnichuk
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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

Igor Sapego-2
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.
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

Dmitry Melnichuk
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
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

dsetrakyan
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
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

Prachi Garg
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
> >>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

Sergey Kozlov
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
Reply | Threaded
Open this post in threaded view
|

Re: Thin Client lib: Python

Dmitry Melnichuk
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.
12