Vladimir, Igniters,
Let's emphasize our final plan.
We are going to add --force flags that will be necessary to pass for a
deactivation if there are in-memory caches to:
1) Rest API (already implemented in [1])
2) Command line utility (already implemented in [1])
3) JMX bean (going to be implemen
Folks,
Found we still use @Nullable annotation.
What's the reason for using it?
Everything is Object and Nullable :)
How about get rid of @Nullable usages and restrict its usage by checkstyle
plugin?
BTW, We already "do not use @NotNull annotation" (с) Coding Guidelines [1]
which may have some
Denis,
In general, code changes look good to me. If we decide to keep security API
in its current state for a while, I highly recommend to extend its
documentation. We don't have descriptive javadocs or articles about
security API so far, so I expect that next contributors will face
difficulties i
Hello, Ivan.
> Is it correct? If we are on the same page, let's proceed this way.
+1 from me for your plan.
> We have removed GridClientClusterState#state(ClusterState) from Java client
> API. Is it a legitimate thing to do? Don't we have to support API
There is no changes in Public API except
Ivan, hi.
1) >>> Is it correct? If we are on the same page, let's proceed this way
It is correct.
2) - In many places in the code I can see the following javadoc
@param forceDeactivation If {@code true}, cluster deactivation will be forced.
In the internal params/flags. You can also fin
I disagree, it would be a step back.
> What's the reason for using it?
Null was a billion dollar mistake [1].
NullPointerExceptions happen quite a lot in Ignite, and annotations provide
some clues to avoid those.
[1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions
On Fri, Mar
I disagree.
Intellij idea IDE has a static code analysis, which uses that
annotation too. IDE highlights possible problems. It helps to make our code
more stable and bugless.
пт, 27 мар. 2020 г. в 12:06, Pavel Tupitsyn :
> I disagree, it would be a step back.
>
> > What's the reason for using it
Hi!
I'm not sure that @Nullable can really fix the NPE problem.
Currently, we have @Nullable annotation and NPE simultaneously.
The best way to avoid NPE is by using a null object pattern.
I agree we shouldn't rely on @Nullable.
пт, 27 мар. 2020 г. в 12:58, Sergey Antonov :
> I disagree.
>
> Int
Here is my opinion. As we do not have a common practice to use
@Nullable and @NotNull annotations everywhere I would consider every
not annotated item as effectively @Nullable. @NotNull seems a useful
annotation for me, sometimes it is a really good thing to assume that
something cannot be null ins
Pavel Pereslegin created IGNITE-12843:
-
Summary: TDE Phase-3. Cache key rotation.
Key: IGNITE-12843
URL: https://issues.apache.org/jira/browse/IGNITE-12843
Project: Ignite
Issue Type: Sub
>>As a temporary solution you can stop relying on peer class loading for
continuous queries and provide the code of remote filters to the classpath
of server nodes.
Yes.. I was thinking of a solution on similar lines. Thank you for the
reply.
--
Sent from: http://apache-ignite-developers.23468
Classification: Public
+1 for using @Nullable.
@Nullable is not panacea, but much better than nothing.
It's clear indication that you should check the marked object for null before
using. There is advantage in using @Nullable than @NotNull - Idea or any tool
like findbugs shows you potential N
+1 for using @Nullable as it is a kind of documentation
+1 for using @NotNull as it protects from
wrong fields/variables assignments if modern IDE is used.
пт, 27 мар. 2020 г. в 14:28, Sergey-A Kosarev :
> Classification: Public
>
> +1 for using @Nullable.
>
> @Nullable is not panacea, but much b
Folks,
First of all, @NotNull already restricted.
And cool guys should use asserts and explicit checks instead of
checked-by-nobody annotations.
Some contributors use vim to write the code, how will it check correctness?
Or we should use only the IDEA?
Second,
>> I would consider every not annota
Good Morning Alexey,
Let me first answer your questions.
1. Are you a member of XGBoost project and have a permission to commit the
XGBoost project? (in many cases the collaboration involves changes in both
integrated frameworks)
No I am not personally, nor is our organization.
2. What are the
Ivan, thank you very much for the review and proposals!
I've made more descriptive JavaDoc; take a look, please.
> Please think about driving creating IEP on security API overhaul prior to
2.9.
Yes, I'll create IEP on security API soon. I also have some ideas about how
we can improve Ignite's sec
Hi guys,
I like the proposal in general.
Now for the task deployment - I think we should have separate API
for it (and separate IEP I believe). Also, I'm not sure that this API
should be a part of the API of any thin client as it seems weird to me
to use Python client to deploy Java tasks. Contro
Agree with Igor, let's set deployment aside for now, it is out of scope of
this IEP.
On Fri, Mar 27, 2020 at 6:52 PM Igor Sapego wrote:
> Hi guys,
>
> I like the proposal in general.
>
> Now for the task deployment - I think we should have separate API
> for it (and separate IEP I believe). Al
Dear Community,
I've just merged and released a new version of the website. Take your time
and enjoy the new look & feel, structure, content, and navigation menu:
https://ignite.apache.org
Thanks to everyone who took part in the most recent Ignite survey [1] and
helped us pinpoint key use cases o
Maxim,
The new website is launched [1] and we can proceed with the changes
discussed in this thread.
Will you have time to implement those next week? If it's highly unlikely
then I would request INFRA to move the website to Git first.
[1]
http://apache-ignite-developers.2346864.n4.nabble.com/ANN
Denis,
I think we can move to git first. I'll do the changes discussed above
by the end of the next week.
On Fri, 27 Mar 2020 at 20:55, Denis Magda wrote:
>
> Maxim,
>
> The new website is launched [1] and we can proceed with the changes
> discussed in this thread.
>
> Will you have time to impl
Denis, this is awesome, thank you!
There is no Blogs page anymore, is that intentional?
On Fri, Mar 27, 2020 at 8:46 PM Denis Magda wrote:
> Dear Community,
>
> I've just merged and released a new version of the website. Take your time
> and enjoy the new look & feel, structure, content, and na
Pavel,
Yes, I removed the page intentionally. None of us had any time to keep that
list up-to-date. I don't think that it will bring any harm as long as
Ignite developers will be googling for topics of interest and all our blogs
(including yours) will pop up at the top of the search results (as lo
Agreed,
I'll ask INFRA to proceed with the Git migration first days next week.
Please wait while the migration ends.
-
Denis
On Fri, Mar 27, 2020 at 11:22 AM Maxim Muzafarov wrote:
> Denis,
>
> I think we can move to git first. I'll do the changes discussed above
> by the end of the next week
Igniters,
Is any of you is skillful enough to contribute improvements to our Python
thin client? For instance, that's one of the tickets that has been recently
reported on the user list:
https://issues.apache.org/jira/browse/IGNITE-12809
-
Denis
Hi Mikhail,
Thank you for help in review. I have merged the changes.
Regards,
Saikat
On Sun, Mar 8, 2020 at 1:39 PM Saikat Maitra
wrote:
> Hi Ilya, Mikhail
>
> I have updated the PR as per review comments.
>
> Please take a look and share your feedback.
>
> PR https://github.com/apache/ignite-
Hello,
I wanted to discuss on merge process for PR in ignite modules when we are
migrating extensions.
I have created these 2 PR for ZeroMQ to migrate from ignite to ignite
extension repo and also to remove ZeroMQ from ignite repo.
https://github.com/apache/ignite-extensions/pull/5
https://gith
Hi,
I have updated the PR as per review feedback.
Please take a look and share your feedback.
Regards,
Saikat
On Sat, Mar 7, 2020 at 2:08 PM Saikat Maitra
wrote:
> Hi Evgenii,
>
> I have responded to your questions and comments.
>
> Please take a look and share your thoughts.
>
> Regards,
> S
28 matches
Mail list logo
