Re: Proposal of new event QUERY_EXECUTION_EVENT

Any objections to create a separate event, which will be fired before executing a query? ср, 2 сент. 2020 г. в 22:33, Dmitrii Ryabov : > > I agree with Max, we need to add a separate event for starting query > execution, and EVT_CACHE_QUERY_EXECUTED shouldn't be deprecated, > because it is

Re: IEP-54: Schema-first approach for 3.0

Ivan, I see your point. I agree that with the automatic updates we step into the schema-last territory. Actually, if we support automatic evolution, we can as well support creating a cache without schema and inferring it from the first insert. In other words, we can have both "schema-first" and

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Ilya. > I'm just saying that we can make it possible as a general principle. +1 to remove as many internal flags as possible. > 7 сент. 2020 г., в 20:20, Ilya Kasnacheev > написал(а): > > Hello! > > I'm not arguing that it should not be discussed. I'm just saying that we > can make it

Re: IGNITE-13407 Upgrade ignite.version to 2.10.0-SNAPSHOT in Ignite Extensions

Hi Ivan, My understanding is in teamcity the build for ignite-extensions is able to pull dependencies from local staging repository http://172.25.4.107/artifactory/gridgain-local Travis is not able to pull the dependencies for the same. I observed that we publish .NET packages in mynuget in

[jira] [Created] (IGNITE-13412) Publish nightly snapshot in apache repository

Saikat Maitra created IGNITE-13412: -- Summary: Publish nightly snapshot in apache repository Key: IGNITE-13412 URL: https://issues.apache.org/jira/browse/IGNITE-13412 Project: Ignite Issue

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Hello! I'm not arguing that it should not be discussed. I'm just saying that we can make it possible as a general principle. Regards, -- Ilya Kasnacheev пн, 7 сент. 2020 г. в 19:01, Nikolay Izhikov : > > We can make a compromise here: we list flags explicitly *but then, we > > > > decide

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

> We can make a compromise here: we list flags explicitly *but then, we > > decide that we don't keep backward compatibility anymore*, since the user > of a new version can check whether their flag is still supported by using > control.sh. It seems removal of any IgniteSystemProperty flag should

Re: [DISCUSSION] Add autocompletion for commands in control.sh

Hello! Not everyone is using bash, which leads me to question whether there's any common approach where we can hint a shell what our executable can do so that it can discover and auto-complete our control.sh Regards, -- Ilya Kasnacheev пн, 7 сент. 2020 г. в 17:47, ткаленко кирилл : > Hello,

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Hello! We do replace some flags with cfg properties, such as inline size, for example. A lot of other flags just duplicate cfg properties. We can make a compromise here: we list flags explicitly *but then, we decide that we don't keep backward compatibility anymore*, since the user of a new

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Ilya. > to remove any expectation of forward compatibility. AFAIK we must keep these flags before Ignite3, due to the backward compatibility. > Flags should be a temporary measure This is not true, for now. I feel your pain :) Personally, I hate these flags, also. But they exist and the

[jira] [Created] (IGNITE-13411) Optimize tracing when NoopTracingSpi is used

Aleksey Plekhanov created IGNITE-13411: -- Summary: Optimize tracing when NoopTracingSpi is used Key: IGNITE-13411 URL: https://issues.apache.org/jira/browse/IGNITE-13411 Project: Ignite

[DISCUSSION] Add autocompletion for commands in control.sh

Hello, folks! I spent time to analyze the possibility of adding auto completion for the "control.sh" with the [1]. To do this, at the beginning, we need to adapt the "control.sh" code to [1], then we can automatically create a "bash completion script" via [2], and then install it, for

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Let me notice that in Ignite 3.0 Wishlist [1] we have a bullet point "Remove as many IGNITE_ parameters as possible from IgniteSystemProperties " [1]

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Hello! Okay, we can do a simple list of these flags, but I would argue that we should: - Avoid adding extra infrastructure such as flags' human readable names, embedded docs, etc. Flags should be a temporary measure. They are now. Let's not make it look like they're there to stay. - Explicitly

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

> what’s the logic? I assume that this is a question to the author of these flags. If you have a specific flag you are interested in, please, write it. My point is simple - we already have these flags. We should explain to the user what we have and what can be configured with these flags.

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

But to Ilya’s point, what’s the logic? Why are some things set using IGNITE_ properties, others on the command line and others in IgniteConfiguration? It’s confusing for the user and makes maintenance harder. I’m not necessarily arguing against this change, though. Perfect being the enemy of

Re: IEP-54: Schema-first approach for 3.0

Ivan, Thank you, I got your concern now. As it is mostly regarding the terminology, I am absolutely fine with changing the name to whatever fits the approach best. Dynamic or evolving schema sounds great. I will make corresponding changes to the IEP once we settle on the name. пн, 7 сент. 2020

[jira] [Created] (IGNITE-13410) .NET: Run Services tests with different service processors

Pavel Tupitsyn created IGNITE-13410: --- Summary: .NET: Run Services tests with different service processors Key: IGNITE-13410 URL: https://issues.apache.org/jira/browse/IGNITE-13410 Project: Ignite

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Hello, Ilya. > I think this is a bad idea since it legitimizes wide use of IGNITE_ > properties, which shows weakness of our configuration API, etc. We already have IGNITE options in the product as a part of public API. See `org.apache.ignite.IgniteSystemProperties`. > 7 сент. 2020 г., в

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Hello! I think this is a bad idea since it legitimizes wide use of IGNITE_ properties, which shows weakness of our configuration API, etc. My take: All of IGNITE_ properties which are useful (and will go to -X) should instead be turned into configuration/metastore settings. All of IGNITE_

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

Alexey, I propose to include [1] issue to the 2.9 release. Since this issue is related to the new master key change functionality which haven't been released yet I think it will be safe to cherry-pick commit to the release branch. [1] https://issues.apache.org/jira/browse/IGNITE-13390 On Tue, 1

Re: [DISCUSSION] control.sh argument to enable experimental commands

Nikolay, thanks for mentioning it. I fetched the last changes and got this: Print metadata command help: control.(sh|bat) --meta help Print list of binary metadata types: control.(sh|bat) --meta list Print detailed info about specified binary type (the type must be specified by type

Re: [DISCUSSION] control.sh argument to enable experimental commands

Philipp, at least, we have tracing and binary meta commands in the master. Please, take a look at current Ignite sources. > 7 сент. 2020 г., в 13:34, Nikolay Izhikov написал(а): > > What is wrong with that? > > We just improve the way user enables experimental commands. > JVM uses similar

Re: [DISCUSSION] control.sh argument to enable experimental commands

What is wrong with that? We just improve the way user enables experimental commands. JVM uses similar approach, please, take a look at '-XX:+UnlockExperimentalVMOptions’. > 7 сент. 2020 г., в 13:22, ткаленко кирилл написал(а): > > Hi, Nikolay! > > It seems that you shouldn't just open

Re: [DISCUSSION] control.sh argument to enable experimental commands

07.09.2020, 13:26, "ткаленко кирилл" : > Adding option "—enable-experimental". > > 07.09.2020, 13:22, "ткаленко кирилл" : >> Hi, Nikolay! >> >> It seems that you shouldn't just open experimental commands, that's why they >> are experimental. >> >> 07.09.2020, 13:03, "Philipp Masharov" : >>>  I

Re: [DISCUSSION] control.sh argument to enable experimental commands

Hello, Kirill. What do you mean by «just open»? > 7 сент. 2020 г., в 13:22, ткаленко кирилл написал(а): > > Hi, Nikolay! > > It seems that you shouldn't just open experimental commands, that's why they > are experimental. > > > 07.09.2020, 13:03, "Philipp Masharov" : >> I will try it.

Re: [DISCUSSION] control.sh argument to enable experimental commands

Hi, Nikolay! It seems that you shouldn't just open experimental commands, that's why they are experimental. 07.09.2020, 13:03, "Philipp Masharov" : > I will try it. Including information about experimental commands into > documentation sounds like a good idea. Am I need to create a Jira

Re: [DISCUSSION] control.sh argument to enable experimental commands

I executed control.sh with the option set to true and set false, made a diff of control.sh outputs and got this: Print absolute paths of unused archived wal segments on each node: control.(sh|bat) --wal print [consistentId1,consistentId2,,consistentIdN] Delete unused archived wal

Re: [DISCUSSION] control.sh argument to enable experimental commands

Philipp, thanks for your interest. You may found useful the following links: https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document Note, right now, we change the way on how we document. Please, take a look into

Re: [DISCUSSION] control.sh argument to enable experimental commands

I will try it. Including information about experimental commands into documentation sounds like a good idea. Am I need to create a Jira ticket? Definitely I need to follow some process to enhance the product documentation. On Mon, Sep 7, 2020 at 12:42 PM Nikolay Izhikov wrote: > Hello, Philipp.

Re: [DISCUSSION] control.sh argument to enable experimental commands

Hello Nikolay! It's more convenient to use an option instead of an environmental variable. But what is experiment commands? Are these commands not production-ready? I never heard about it and I can't find information about experiment commands in the product documentation. On Mon, Sep 7, 2020 at

[DISCUSSION] control.sh argument to enable experimental commands

Hello, Igniters. For now, experimental commands in control.sh can be enabled only via system property ``` $ export IGNITE_ENABLE_EXPERIMENTAL_COMMAND="true" $ ./bin/control.sh ``` I think we should add explicit argument for this. ``` ./control.sh —enable-experimental ``` WDYT?

[jira] [Created] (IGNITE-13409) System view for metastorage items

Nikolay Izhikov created IGNITE-13409: Summary: System view for metastorage items Key: IGNITE-13409 URL: https://issues.apache.org/jira/browse/IGNITE-13409 Project: Ignite Issue Type:

[jira] [Created] (IGNITE-13408) System view for binary metadata

Nikolay Izhikov created IGNITE-13408: Summary: System view for binary metadata Key: IGNITE-13408 URL: https://issues.apache.org/jira/browse/IGNITE-13408 Project: Ignite Issue Type:

Re: IGNITE-13407 Upgrade ignite.version to 2.10.0-SNAPSHOT in Ignite Extensions

Hi Saikat, Thank you for working on it! I noticed that Travis build for the PR failed to resolve 2.10.0-SNAPSHOT dependency as well. Could you please hint me how Ignite SNAPSHOT dependencies (ignite-core and so on) are intended to be available to ignite-extensions builds? 2020-09-06 22:01

Re: IEP-54: Schema-first approach for 3.0

Hi Val, Thank you for your answer! My understanding is a little bit different. Yes, schema evolution definitely should be possible. But I see a main difference in "how schema is updated". I treat a common SQL approach schema-first. Schema and data manipulation operations are clearly separated