I've created ticket for it https://issues.apache.org/jira/browse/IGNITE-14911
ср, 16 июн. 2021 г. в 08:37, Ivan Daschinsky :
>
> Ops, i don't even know about it. I believe that this is so rarely used, i
> don't even noticed it. I am talking about transactions and expiry policy. I
> suppose that
I have a compromise variant.
1. Large timeouts are set usually only for expire_policy. I suggest to
support datetime.timedelta here and int as milliseconds
2. All others timeouts should accept only ints as milliseconds.
3. Only timeout in Connection as sockettimeout should remain float in
seconds,
Dear Ignite Community!
I propose to discuss the addition of a new feature for control script:
cache statistics switch (enabling / disabling). Currently, cache statistics
can be toggled only via IgniteVisorCmd or JMX.
I've created the corresponding issue [1] and suggest adding an extra option
to a '
Hi,
I think that scope should be limited by public API for beginning.
Also I don't sure that we should support specific tags like @apiNote,
@implSpec, @implNote.
Let's move using the following plan:
1. Create an empty (effectively) checkstyle config for javadoc
checking and commit it to the rep
Konstantin, thanks for chiming in.
That's exactly my concern. Overformalization is generally not a good thing.
Someone used "mess" to abbreviate "message"? That is surely not a good
coding style, but that's what code reviews are for. I believe that our
committers are more than capable of identifyi
I propose to cancel this release and fix the issue which was highlighted in
the
"Seconds and milliseconds confusion in python thin client" thread.
WDYT?
Best Regards,
Igor
On Wed, Jun 16, 2021 at 12:10 AM Igor Sapego wrote:
> +1 from me
>
> Uploaded to test.pipy.org: https://test.pypi.org/pro
Hi,
I understand that this rule seems too strict or may be weird. But
removing the rule could lead to review comments like "use future
instead of fut". So my proposal is to change rule from "required" to
"recommended".
On Wed, Jun 16, 2021 at 2:49 PM Valentin Kulichenko
wrote:
>
> Konstantin, th
Yes, I agree, after merging
https://issues.apache.org/jira/browse/IGNITE-14911 that resolves this
issue, I suggests to start a new vote.
ср, 16 июн. 2021 г. в 15:54, Igor Sapego :
>
> I propose to cancel this release and fix the issue which was highlighted in
> the
> "Seconds and milliseconds conf
Hi, Ilya
Could you please provide more details about how it should work (in
issue description)? E.g. what if I pass the cache group name instead
of the name of a particular cache? What if I will not pass any cache
names?
Also we don't use the word "statistics" anymore (while it is still
called st
This vote was canceled since it was decided to add [1] to the release.
[1] has been already merged to master branch and cherrypicked to
release branch. New vote will be created soon.
[1] -- https://issues.apache.org/jira/browse/IGNITE-14911
Dear Igniters!
Release candidate binaries for subj are uploaded and ready for vote
You can find them here:
https://dist.apache.org/repos/dist/dev/ignite/pyignite/0.5.0-rc1
If you follow the link above, you will find source package (*.tar.gz and *.zip)
and binary packages (wheels) for windows (amd
The vote will end at June, 17 15:00 UTC.
ср, 16 июн. 2021 г. в 17:33, Ivan Daschinsky :
>
> Dear Igniters!
>
> Release candidate binaries for subj are uploaded and ready for vote
> You can find them here:
> https://dist.apache.org/repos/dist/dev/ignite/pyignite/0.5.0-rc1
>
> If you follow the link
Hi,
In my strong opinion Javadoc is a code. Any errors in Javadoc are
equal to the bug in the code and must be treated as such. Proper and
extensive Javadoc for all public and many private APIs is absolutely
essential for this project, its growth and maturity.
I'm surprised this community still ne
Consistency is what makes it easier to contribute to the project and
attract new members. Consistency implies strong, well defined and
universally enforced rules. Just because we have some individuals who
are lazy or inexperienced - it does not mean that the entire project
should relax the basic-le
Nikita,
Do you have a plan in your mind how to make Ignite codebase consistent?
AFAIR, we had it intentionally inconsistent for a long time at least
for one sake: for internal code we used special conventions (e.g.
abbreviations, shorten getters) and common Java conventions for public
API and exa
Hello, Ivan.
We can create checkstyle rule to enforce usage of abbreviations.
Internal/public code differs by package.
PoC of rule [1]
[1] https://github.com/apache/ignite/pull/9153
> 17 июня 2021 г., в 07:01, Ivan Pavlukhin написал(а):
>
> Nikita,
>
> Do you have a plan in your mind how to
Hi Nikolay,
Thanks, it is rather interesting.
Do we all agree that using different conventions for different code
packages does not break "consistency"? Or did I get something wrong?
2021-06-17 7:12 GMT+03:00, Николай Ижиков :
> Hello, Ivan.
>
> We can create checkstyle rule to enforce usage of
17 matches
Mail list logo
