Thanks Dmitry!
On Wed, Sep 5, 2018 at 11:59 PM, Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:
> Hello, Prachi!
>
> The section is a hand-written .rst-file, which contains links to some
> content, generated from code with `sphinx-apidoc`.
>
> All autogenerated content resides in `sourc
Hello, Prachi!
The section is a hand-written .rst-file, which contains links to some
content, generated from code with `sphinx-apidoc`.
All autogenerated content resides in `source` folder. For example, this
is an autogenerated page:
https://apache-ignite-binary-protocol-client.readthedocs.
Hi Dmitry M,
Is the API Specification [1] section of the documentation auto-generated
from the code?
[1]
https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/modules.html
On Mon, Jul 30, 2018 at 5:05 PM, Dmitriy Setrakyan
wrote:
> Now we are talking. A much better and more use
Now we are talking. A much better and more user-friendly API.
D.
On Fri, Jul 27, 2018 at 7:19 AM, Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:
> Dmitriy, Igor, Ilya, Sergey!
>
> Thank you for sharing your ideas, concerns and criticism with me. I do
> appreciate it.
>
> I already mad
Dmitriy, Igor, Ilya, Sergey!
Thank you for sharing your ideas, concerns and criticism with me. I do
appreciate it.
I already made some changes in my API, influenced by your feedback. I
also plan to add a certain set of features, that will make my UX closer
to what you can see from other Igni
Dmitriy,
I would stop using the word "hashcode" in this context. Hash code has a
special meaning in Ignite and is used to determine key-to-node affinity. I
agree that passing "cache_name" is the best option. I have no idea when
"cache_name" is not going to be known and do not think we need to supp
Thanks Dmitry. I'll look at the docs.
On Wed, Jul 25, 2018 at 8:11 PM, Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:
> Hi Prachi!
>
> At the moment I already have my documents (temporarily) published at RTD.
> This is how they look like at a whole:
>
> https://apache-ignite-binary-pro
Hello!
I expect the effect to be neligible, and UX gain is well worth it.
In case it will ever become a sensitive issue, hashcode-based operation
might be retained as mentioned earlier.
Regards,
--
Ilya Kasnacheev
2018-07-26 17:39 GMT+03:00 Igor Sapego :
> Ilya,
>
> This may affect performan
Ilya,
This may affect performance in a negative way, as it requires
additional hashcode calculation on every cache operation.
Best Regards,
Igor
On Thu, Jul 26, 2018 at 5:02 PM Ilya Kasnacheev
wrote:
> Hello!
>
> I think that having both options is indeed preferable.
>
> Regards,
>
> --
> Ily
Hello!
I think that having both options is indeed preferable.
Regards,
--
Ilya Kasnacheev
2018-07-26 16:51 GMT+03:00 Dmitry Melnichuk
:
> Hi, Ilya!
>
> I considered this option. Indeed, the code would look cleaner if only one
> kind of identifier (preferably the human-readable name) was used
Hi, Ilya!
I considered this option. Indeed, the code would look cleaner if only
one kind of identifier (preferably the human-readable name) was used.
But there can be a hypothetical situation, when the user is left with
hash code only. (For example, obtained from some other API.) It would be
Hello!
Why not use cache name as string here, instead of cache_id()?
cache_put(conn, 'my-cache', value=1, key='a')
Regards,
--
Ilya Kasnacheev
2018-07-26 5:11 GMT+03:00 Dmitry Melnichuk :
> Either
>
> ```
> conn = Connection('example.com', 10800)
> cache_put(conn, cache_id('my-cache'), 'a',
Hi Prachi!
At the moment I already have my documents (temporarily) published at
RTD. This is how they look like at a whole:
https://apache-ignite-binary-protocol-client.readthedocs.io/
I already have a separate section on examples:
https://apache-ignite-binary-protocol-client.readthedocs.io/
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.
```
con
Also I remember there are no hashcodes for NodeJS clients
On Wed, Jul 25, 2018 at 10:46 PM, 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
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
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
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 wh
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 <
dmitry.melnic...@nobitlost.com> wrote:
> Dmitriy,
>
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 system
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”
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 wi
Dmitriy,
To be honest, I got a bit lost in such a big email. Can you tell us briefly
- why do we not need the hash code on API in Java and we do need it in
Python?
D.
On Wed, Jul 25, 2018 at 3:29 AM, Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:
> Hello, Dmitriy, Igor!
>
> Dmitriy,
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 en
Yes, looks strange? Why is the hash code part of API?
On Tue, Jul 24, 2018, 13:38 Igor Sapego 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)
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
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, virtualen
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 ge
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
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://a
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 <
dmitry.melnic...@nobitlost.com> wrote:
> Hello Ignite developers!
>
> I would like to bring to your attention, that the n
31 matches
Mail list logo
